On Wednesday 18 July 2007 7:33:19 pm Kay Sievers wrote:
> On 7/18/07, Rob Landley <[email protected]> wrote:
> > > > /sys/block/*/dev
> > > > /sys/block/*/*/dev
> > >
> > > Note that this will change to /sys/class/block/ in the future.
> >
> > At OLS, Kay Sievers said in a future version they were going to move it
> > to "/sys/subsystem/block", which I can't document right now because no
> > current kernel does this, and that path will never work with any previous
> > kernel, but there should be a compatability symlink from the old path to
> > the new one.
>
> That will be the case.
>
> > He never mentioned /sys/class/block.
>
> So? How about reading your email?
> http://marc.info/?l=linux-kernel&m=118260305012165&w=2
It wasn't in the notes you sent me from OLS, and I didn't compare against the
earlier one because I thought the OLS notes were complete.
> Yes, in this order (if you want to use it, but /sys/block will still be
> there): /sys/subsytem/block/devices/*
> /sys/class/block/*
> /sys/block/*/*
"if you want to use it" said to me that sys/class/block/* was optional, so I
didn't add it to the document I was writing.
> You seem to miss the the very basic skills to collect the needed
> information to do the job of documenting something.
I've gotten a lot of contradictory information, a lot of gratuitous changes
from previous versions, a lot of notice of as of yet unmerged plans, and a
lot of useless information (mostly in the form of "don't"s) while researching
this topic. I'm trying to find a useful subset.
I asked you what I needed when we met in person, and you didn't
put /sys/class/block/* in the list.
Sysfs is almost unique in that examining the implementation tells me NOTHING
about how to use it. This is a defect in sysfs that I'm attempting to
rectify by writing documentation about what you can rely on when trying to
use it for hotplug and firmware loading. This is a specific, limited use
that I'm familiar with the requirements for.
Is there anything in /sys/class/block that _isn't_ in /sys/block? Does "if
you want to use it, but /sys/block will still be there" NOT mean, as I
assumed at the time, that I could safely ignore it? (My impression from the
meeting at OLS was that adding /sys/block to /sys/class/block had been just
an idea rejected in favor of adding it to /sys/subsystem/block. I note that
neither my Ubuntu 7.04 laptop nor the 2.6.22 system I built has either
a /sys/class/block or a /sys/subsystem/block, so anything written attempting
to use that won't work on any currently deployed Linux system. You can't use
it today, and will never be able to use it on any kernel version deployed
today.)
> > To all of this, I would like to humbly ask:
> >
> > PICK ONE! JUST #*%(&#%& PICK ONE! AAAAAAAAHHHHHHH!!!!!!!!!
>
> Man, you totally miss the point.
I want to document a stable API, including the subset of sysfs that will
remain stable. The "point" appears to be that there isn't one because sysfs
is "special", and udev should be in the kernel source tarball.
I'm trying to write down here the minimal information needed to find the "dev"
nodes to populate /dev. There's no functional reason I'm aware of for them
to keep moving around.
> > > > Entries for char devices are found at the following locations:
> > > >
> > > > /sys/bus/*/devices/*/dev
> > > > /sys/class/*/*/dev
> > >
> > > Uh, that is actually the generic location?
> >
> > It's what Kay Sievers and Greg KH told me at OLS when I tracked them down
> > to ask. I've also experimentally verified it working on Ubuntu 7.04.
> > That was cut and pasted from Kay's email, and it works today.
>
> That is still true, but it still does not tell you the type of node to
> create, as you seem to insist on.
I don't insist on it, mknod insists on it. You cannot mknod a dev node
without specifying block or char.
You're saying that sysfs should provide major and minor numbers without
anywhere specifying "char" or "block", meaning the major and minor numbers
cannot be _used_. I am insisting on getting the third piece of information
without which "major" and "minor" are useless.
I asked very specifically about this at OLS, several times. What you're
telling me now seems to contradict what you told me then.
What I documented works in today's kernel. You've talked about adding new
mechanisms that won't work in today's kernel, which I'm not worrying about as
long as the mechanisms that work with today's kernel continue to work. Now
you say you're going to break today's kernel by adding block devices
to /sys/class, which I got the impression was NOT going to happen at OLS
(that it was going to move to sys/subsystem but that sys/block symlink would
still track it). I specifically asked "what paths do I need to look at to
find char devices" and "what paths do I need to look at to find block
devices", and the paths in the documentation are the ones I got when I asked.
If block is going to move to sys/class, I can put in a warning about this
pending breakage in the documentation, and modify my example code to filter
it out.
> > > It may be enough (and less confusing) to just state that the dev
> > > attribute will belong to the associated "class" device sitting
> > > under /sys/class/ (with the current exception of /sys/block/).
> >
> > Nope. If you recurse down under /sys/class following symlinks, you go
> > into an endless loop bouncing off of /sys/devices and getting pointed
> > back. If you don't follow symlinks, it works fine up until about 2.6.20
> > at which point things that were previously directories BECAME symlinks
> > because the directories got moved, and it all broke.
>
> That's total nonsense.
Which part, the "following symlinks produced an endless loop" or
the "directories turned into symlinks so not following them broke?"
Let's see...
According to my blog, Frank Sorensen first sent me a C port of my /dev
populating script on December 12, 2005. The current kernel at the time was
2.6.14, so grab that, build user Mode Linux... Huh, it won't build with gcc
4.1.2. Or 3.4. Ok, defconfig? Nope, that wants a stack check symbol?
Let's see... Ah, google says add -fno-stack-protector to CFLAGS. Right...
Fire it up under qemu, "mount -t sysfs /sys /sys", and:
In 2.6.14, /sys/block/hda/device points
to ../../devices/pci0000:00/0000:00:01.1/ide0/0.0
/sys/block/hda/device/block points to ../../../../../block/hda
So in 2.6.14 you could
go /sys/block/hda/device/block/device/block/device/block... endlessly, which
is the reason I wrote mdev not to follow symlinks but to instead only look at
actual subdirectories. (It uses the same code to traverse down
beneath /sys/block and /sys/class to look for "dev" entries.) This works
fine up through the 2.6.20 in ubuntu 7.04, where everything
in /sys/class/tty/* is still a subdirectory. But in 2.6.22, /sys/class/tty/*
is all symlinks. Hence the code that was working before changed, due to
something that worked fine for a couple years but broke because it wasn't
considered part of a stable API.
Which part of this is "total nonsense"?
> > Which is why I want it documented where to look for these suckers. Just
> > give me ONE STABLE WAY TO FIND THIS INFORMATION, PLEASE.
> >
> > This document is trying to document just enough information to make
> > hotplug work using sysfs (which includes firmware loading if necessary).
> >
> > > (And how about referring to Documentation/sysfs-rules.txt?)
> >
> > Because there isn't one in 2.6.22, and I've been writing this file on and
> > off for a month as I tracked down various bits of information?
>
> I invested a lot of time explaining stuff to you in email and
> personally, but really, that seems just like a total waste of time.
I wrote up a document. Started writing it before OLS, incorporated the
information I got from you while at OLS, and took a while tracking down some
old code doing netlink so I could include enough for people to puzzle out how
that works.
I would have bounced earlier unfinished drafts off of you, but you were
spam-blocking my email. (Might still be, I don't know. This is why I wanted
to talk to you in person at OLS.)
> I will not reply to any of your mails
And I _can't_ reply to yours off-list because of your out of control spam
filter.
> until you have proven to have read
> the udevtrigger code,
I read the udev code when it was first posted. I read it again 20 versions
later, and read it again 20 versions after that. I couldn't COMPILE the darn
thing for its first ~40 releases, the code got ripped out and re-written
several times, I watched as it grew and then threw out libsysfs.
So essentially you're saying "well read it again, we've finally got it right
now"?
> and got a clue how to do stuff reliably, and get
> the basic knowledge needed to document it.
Because talking to you and having you email me the notes from this
conversation did not provide the basic knowledge needed to document hotplug
and firmware loading. Nor did asking for feedback on the document I wrote
up. Thanks ever so much.
I point out that udev changes from version to version, so that running an old
version of udev against a new kernel has been known to break. Udev was more
or less completely rewritten three times while I was still paying attention
to it. Reading the udev code and seeing what it's doing struck me as about
as likely to reveal a stable API as reading the kernel source, or
experimenting with sysfs from userspace. (Both of which I've _done_ at
various points, and it keeps changing.)
Are you saying that the current version of udev will work with all future
kernels, and thus if I can figure out what udev is doing today, I can just
document that as the stable API?
> Kay
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
