Re: Documentation for sysfs, hotplug, and firmware loading.
On Mon, 23 Jul 2007, Rob Landley wrote: > On Saturday 21 July 2007 8:14:41 am Bodo Eggert wrote: > > Greg KH <[EMAIL PROTECTED]> wrote: > > > On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote: > > >> I'm not trying to document /sys/devices. I'm trying to document > > >> hotplug, populating /dev, and things like firmware loading that fall out > > >> of that. This requires use of sysfs, and I'm only trying to document as > > >> much of sysfs as you need to do that. > > > > > > Like I stated before, you do not need to even have sysfs mounted to have > > > a dynamic /dev. > > > > > > And why do you need to document populating /dev dynamically? udev > > > already solves this problem for you, it's not like people are going off > > > and reinventing udev for their own enjoyment would not at least look at > > > how it solves this problem first. > > > > Turning your words around, you get: "Whatever one of these programs does > > documents how dynamic devices should be handled." If this is true, any > > change that makes one of these programs break is a kernel bug. > > > > Besides that: How am I supposed to be able to correctly change udev if > > there is no document telling me what would work and what happens to > > work by accident? > > You aren't expected to. Remember that udev and sysfs are written by the same > people, working together off-list. They're free to break the exported data > format on a whim, because they write the code at both ends and fundamentally > they're talking to themselves. They honestly say you can't expect a new > kernel to work with an old udev, and they say it with a straight face. (To > me, this sounds like saying you can't expect a new kernel to work with an old > version of ps, because of /proc.) > > Documentation is a threat to this way of working, because it would impose > restrictions on them. A spec is only of use if you introduce the radical > idea that the information exported by sysfs exists for some purpose _other_ > than simply to provide udev with information (and a specific version of udev > matched to that kernel version, at that). And having no documentation is, as you can see in this thread, a threat to open software. Having exactly one blob of software, and being left on your own once you change a bit, is one step away from having a binary only module. > > > To do otherwise would be foolish :) > > > > Some people like to fool around and create even smaller wheels. > > E.g. I'm changing the ACPI button driver to just call Ctrl_alt_del > > in order not to have an extra process running and free 0.2 % of my RAM. > > When I started looking at udev in 2005, it was a disaster. My commentary at > the time is at http://lkml.org/lkml/2005/10/30/189 and the relevant bit is: [...] > And so I made mdev, a utility which populated /dev _with_ a config file in > 7k. > Greg's upset I didn't just patch udev to remove libsysfs, remove the > duplicated klibc code, remove the gratuitous database, remove the > overcomplicated config file parser (with rules compiler), and so on. They're > boggling that I could ever have been unhappy with the One True Project to > populate /dev. I see, we agree on this point. Besides that, I like to see the steps to be done, instead of having a letter sent to a voodoo doctor in Africa (called udev) and getting back a magic spell to be chanted on my system (unless he just pokes some voodoo doll). -- Top 100 things you don't want the sysadmin to say: 87. Sorry, the new equipment didn't get budgetted. - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Tuesday 24 July 2007 2:38:18 am Greg KH wrote: > > In other words: Grasping sysfs is not a feasible task? If this is true, > > how can anybody reliably use sysfs? > > Huh, I never stated that at all. If you wish to fully document sysfs > and how it works, then great, do that. But that was not the stated > intent of this document, and is why I think the author got confused as > he was attempting to put a narrow portion of how sysfs works as a > reflection on how the whole of the body works. I am often confused. Confusion is my natural state. It's how I got started writing documentation, as "notes to me" so I'd be able to reproduce what I did. Currently my "one more thing to research before I can write this up" is your earlier comment that I can coldplug the existing set of devices without talking to sysfs. Possibly there's a way to do this through netlink, but I don't know of any way to send data _back_ to the kernel with the usermode helper mechanism, and telling the kernel to do that for every device in the system at once seems like a fork bomb waiting to happen anyway. Yes, some embedded developers want to remove the networking layer from the kernel, meaning they can't use netlink, meaning if we ever _do_ go to dynamically allocated /dev nodes and you _must_ populate /dev by getting the numbers out of the kernel, this is an issue. So far, I've been able to devote about 15 minutes to this topic since the weekend, and that was stolen from something else... > thanks, > > greg k-h 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Mon, 23 Jul 2007 19:26:54 -0400, Rob Landley <[EMAIL PROTECTED]> wrote: Sorry, that's way too much for me to bother reading. I'd look at any patches against the existing documentation, though. But I'll stop looking at this thread, there's too much ranting for my taste in there. - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Sat, Jul 21, 2007 at 02:14:41PM +0200, Bodo Eggert wrote: > Greg KH <[EMAIL PROTECTED]> wrote: > > On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote: > > >> I'm not trying to document /sys/devices. I'm trying to document hotplug, > >> populating /dev, and things like firmware loading that fall out of that. > >> This requires use of sysfs, and I'm only trying to document as much of > >> sysfs > >> as you need to do that. > > > > Like I stated before, you do not need to even have sysfs mounted to have > > a dynamic /dev. > > > > And why do you need to document populating /dev dynamically? udev > > already solves this problem for you, it's not like people are going off > > and reinventing udev for their own enjoyment would not at least look at > > how it solves this problem first. > > Turning your words around, you get: "Whatever one of these programs does > documents how dynamic devices should be handled." If this is true, any > change that makes one of these programs break is a kernel bug. Not at all. The kernel changed things numerous times that showed up as bugs in udev, and I fully admit that (and have in the past, numerous times.) > Besides that: How am I supposed to be able to correctly change udev if > there is no document telling me what would work and what happens to > work by accident? Um, the same way you change any codebase? :) > > To do otherwise would be foolish :) > > Some people like to fool around and create even smaller wheels. > E.g. I'm changing the ACPI button driver to just call Ctrl_alt_del > in order not to have an extra process running and free 0.2 % of my RAM. That's great, and I have nothing against that, and encourage you to do so. But I don't suppose you are trying to complain to the ACPI developers about this whole thing now are you? Are you hasseling them and demanding that they fully document their interfaces that you need to use so that you can hook into their code differently than they wish you to do so? > > Firmware loading is fine to document if you wish to do so. But again, > > why? We already have multiple userspace programs that provide this > > feature for them. Perhaps you want to document how to add firmware to a > > system in order for these different programs to pick them up? > > I once tried to install a firmware for hotplug. Even finding the place whre > I'm supposed to put it was harder than rewriting that *beep* from start, > but I could not rewrite it because I didn't have any documentation. The firmware layer has never been fully documented, and the maintainer of the code died a few years ago. It has been well known that this is one area of the kernel that needs a lot of attention and help. Please feel free to chip in if you can do so. > Even digging in that pile of wrapper scrips in order to debug that thing > was a nightmare. (Having a number of places where the firmware will be > expected in one of many versions and formats stored using one of many > filenames can drive you nuts.) I fully agree. > > Or perhaps you want to document how to add this kind of functionality to > > your kernel driver so that it can handle firmware loading by using the > > firmware interface that the kernel provides? > > I suppose that's missing, too. Or scattered in a number of contradicting > and mostly outdated howtos across the internet. Ir proably is, hence my suggestion on something that would be very valuable to have documented. > > If you just want to document the hotplug/uevent api, then do just that. > > However I think you are overreaching with your scope here and getting > > mighty confused in the process. > > In other words: Grasping sysfs is not a feasible task? If this is true, > how can anybody reliably use sysfs? Huh, I never stated that at all. If you wish to fully document sysfs and how it works, then great, do that. But that was not the stated intent of this document, and is why I think the author got confused as he was attempting to put a narrow portion of how sysfs works as a reflection on how the whole of the body works. thanks, greg k-h - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Friday 20 July 2007 8:43:49 pm Greg KH wrote: > On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote: > > Ok, back up. /sys/devices does not contain all the information necessary > > to populate /dev, because it hasn't got things like > > ramdisks, /dev/zero, /dev/console which are THERE in sysfs, which may or > > may not be supported by the kernel (the kernel might have ramdisk > > support, might not). > > Welcome to 2007: > > $ ls /sys/devices/virtual/mem/ > full kmem kmsg mem null port random urandom zero > $ ls /sys/devices/virtual/tty/ > console tty12 tty19 tty25 tty31 tty38 tty44 tty50 tty57 tty63 > ptmx tty13 tty2 tty26 tty32 tty39 tty45 tty51 tty58 tty7 > tty tty14 tty20 tty27 tty33 tty4 tty46 tty52 tty59 tty8 > tty0 tty15 tty21 tty28 tty34 tty40 tty47 tty53 tty6 tty9 > tty1 tty16 tty22 tty29 tty35 tty41 tty48 tty54 tty60 > tty10tty17 tty23 tty3 tty36 tty42 tty49 tty55 tty61 > tty11tty18 tty24 tty30 tty37 tty43 tty5 tty56 tty62 > > I suggest you take a close look at the kernel before making statements > like the above :) I did: [EMAIL PROTECTED]:/sys/devices$ ls /sys/devices/virtual ls: /sys/devices/virtual: No such file or directory [EMAIL PROTECTED]:/sys/devices$ cat /proc/version Linux version 2.6.20-16-generic ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Thu Jun 7 20:19:32 UTC 2007 I.E. Ubuntu 7.04, stock. The most recent release, using a 2.6.20 kernel. I see that what you're talking about is in 2.6.22. Back when I started writing my document in May, I forgot to check 2.6.22. > > These things could also, in future, have their major and minor numbers > > dynamically (even randomly) assigned. That's been discussed on this > > list. > > I tried that once, it will require some core api kernel changes and a > lot of infrastrucure work to get that to work properly. Not that it > will never happen in the future, but it's just not a trivial change at > the moment... Understood. > thanks, > > greg k-h 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Saturday 21 July 2007 8:14:41 am Bodo Eggert wrote:
> Greg KH <[EMAIL PROTECTED]> wrote:
> > On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote:
> >> I'm not trying to document /sys/devices. I'm trying to document
> >> hotplug, populating /dev, and things like firmware loading that fall out
> >> of that. This requires use of sysfs, and I'm only trying to document as
> >> much of sysfs as you need to do that.
> >
> > Like I stated before, you do not need to even have sysfs mounted to have
> > a dynamic /dev.
> >
> > And why do you need to document populating /dev dynamically? udev
> > already solves this problem for you, it's not like people are going off
> > and reinventing udev for their own enjoyment would not at least look at
> > how it solves this problem first.
>
> Turning your words around, you get: "Whatever one of these programs does
> documents how dynamic devices should be handled." If this is true, any
> change that makes one of these programs break is a kernel bug.
>
> Besides that: How am I supposed to be able to correctly change udev if
> there is no document telling me what would work and what happens to
> work by accident?
You aren't expected to. Remember that udev and sysfs are written by the same
people, working together off-list. They're free to break the exported data
format on a whim, because they write the code at both ends and fundamentally
they're talking to themselves. They honestly say you can't expect a new
kernel to work with an old udev, and they say it with a straight face. (To
me, this sounds like saying you can't expect a new kernel to work with an old
version of ps, because of /proc.)
Documentation is a threat to this way of working, because it would impose
restrictions on them. A spec is only of use if you introduce the radical
idea that the information exported by sysfs exists for some purpose _other_
than simply to provide udev with information (and a specific version of udev
matched to that kernel version, at that).
> > To do otherwise would be foolish :)
>
> Some people like to fool around and create even smaller wheels.
> E.g. I'm changing the ACPI button driver to just call Ctrl_alt_del
> in order not to have an extra process running and free 0.2 % of my RAM.
When I started looking at udev in 2005, it was a disaster. My commentary at
the time is at http://lkml.org/lkml/2005/10/30/189 and the relevant bit is:
> It turns out udev is smaller than it seems because it block copies
> code out of klibc and libsysfs (yes, having a standard interface library to
> sysfs is _such_ a good idea we should fork our own copy and bundle it.
> After all, that's what shared libaries are for...) And once you chop out
> all that, 90% of what's left is _still_ optional (try "grep ' main(' *.c'"
> and notice we have 12 separate occurrences of main(). For something that
> needs at most two (bootup and hotplug) and the bootup version can be a
> command line option. You don't need udevinfo, udevmonitor, udevsend, or
> udevtest.) Add in the fact that udev/udevd use a gratuitous database that
> can be ditched, and then contemplate simplifying the config file (cut down
> the parser, and embedded users should NOT need a rules compiler; dunno
> whether it's worth it to keep the same config file syntax or come up with
> something tiny and dumb for embedded use)...
And so I made mdev, a utility which populated /dev _with_ a config file in 7k.
Greg's upset I didn't just patch udev to remove libsysfs, remove the
duplicated klibc code, remove the gratuitous database, remove the
overcomplicated config file parser (with rules compiler), and so on. They're
boggling that I could ever have been unhappy with the One True Project to
populate /dev.
> > Firmware loading is fine to document if you wish to do so. But again,
> > why? We already have multiple userspace programs that provide this
> > feature for them. Perhaps you want to document how to add firmware to a
> > system in order for these different programs to pick them up?
>
> I once tried to install a firmware for hotplug. Even finding the place whre
> I'm supposed to put it was harder than rewriting that *beep* from start,
> but I could not rewrite it because I didn't have any documentation.
> Even digging in that pile of wrapper scrips in order to debug that thing
> was a nightmare. (Having a number of places where the firmware will be
> expected in one of many versions and formats stored using one of many
> filenames can drive you nuts.)
One of my todo list items is to see if loading firmware out of initramfs for
statically linked devices, before /init gets spawned, can be made to work.
Documenting how it works under normal circumstances is step 1.
Then again I'm wierd and think that documentation is a good thing in
itself. "You want to document this? Why would you do a crazy thing like
that?" Because I'm that kind of crazy? Because people have _ASKED_ me for
this documentation off-list
Re: Documentation for sysfs, hotplug, and firmware loading.
Greg KH <[EMAIL PROTECTED]> wrote: > On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote: >> I'm not trying to document /sys/devices. I'm trying to document hotplug, >> populating /dev, and things like firmware loading that fall out of that. >> This requires use of sysfs, and I'm only trying to document as much of sysfs >> as you need to do that. > > Like I stated before, you do not need to even have sysfs mounted to have > a dynamic /dev. > > And why do you need to document populating /dev dynamically? udev > already solves this problem for you, it's not like people are going off > and reinventing udev for their own enjoyment would not at least look at > how it solves this problem first. Turning your words around, you get: "Whatever one of these programs does documents how dynamic devices should be handled." If this is true, any change that makes one of these programs break is a kernel bug. Besides that: How am I supposed to be able to correctly change udev if there is no document telling me what would work and what happens to work by accident? > To do otherwise would be foolish :) Some people like to fool around and create even smaller wheels. E.g. I'm changing the ACPI button driver to just call Ctrl_alt_del in order not to have an extra process running and free 0.2 % of my RAM. > Firmware loading is fine to document if you wish to do so. But again, > why? We already have multiple userspace programs that provide this > feature for them. Perhaps you want to document how to add firmware to a > system in order for these different programs to pick them up? I once tried to install a firmware for hotplug. Even finding the place whre I'm supposed to put it was harder than rewriting that *beep* from start, but I could not rewrite it because I didn't have any documentation. Even digging in that pile of wrapper scrips in order to debug that thing was a nightmare. (Having a number of places where the firmware will be expected in one of many versions and formats stored using one of many filenames can drive you nuts.) > Or perhaps you want to document how to add this kind of functionality to > your kernel driver so that it can handle firmware loading by using the > firmware interface that the kernel provides? I suppose that's missing, too. Or scattered in a number of contradicting and mostly outdated howtos across the internet. > If you just want to document the hotplug/uevent api, then do just that. > However I think you are overreaching with your scope here and getting > mighty confused in the process. In other words: Grasping sysfs is not a feasible task? If this is true, how can anybody reliably use sysfs? -- Top 100 things you don't want the sysadmin to say: 99. Shit!! Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Friday 20 July 2007 3:00:01 am Greg KH wrote: > On Fri, Jul 20, 2007 at 01:14:27AM -0400, Rob Landley wrote: > > Is there anything in /sys/class/block that _isn't_ in /sys/block? > > No. > > > 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? > > Ignore what? /sys/block? If you see /sys/class/block, then yes, you > can ignore it as they are just symlinks back to each other. I read "if you want to use it" as meaning "if you want to use "/sys/class/block", I.E. it was optional. If /sys/block is going to remain a symlink to /sys/class/block then using the path "/sys/block" should work on both existing kernels and on new kernels without modification. What moving it will force me to do is edit out "/sys/class/block' if I find it looking for char devices under "/sys/class". Moving it forces me to add code to remove it. I don't know what the supposed benefit is... Ah, hang on. Most likely this is an implementation detail from moving everything under /sys/subsystem and making /sys/class a symlink -> subsystem and /sys/block a symlink -> subsystem/block. So it sounds like it's not really intentional breakage, just an implementation side effect. Ok, that makes sense. (Sorry, this hadn't occurred to me until now. I'm not the one implementing this stuff, so I haven't spent the past few months thinking through the ramifications already. This entire thread is one of about 12 things I'm working on at the moment.) > > (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. > > No, the /sys/class/block is in -mm and has been for some time. A yes, "set back up an automated -mm testing thing that away when previous laptop did". I need to bump that up on my todo list... > > 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.) > > Not true at all, it works just fine here on my machines, and on all > distros released in the past year or so as tested out by a lot of users. "All the distros" meaning "not Ubuntu 7.04"? I just checked again, it doesn't have either a /sys/class/block or /sys/subsystem/block. I realize they're coming... > The only reason it isn't in Linus's tree just yet, is that some very old > mkinitrd programs don't seem to like it (we are talking Fedora Core 3 > based distros, not Fedora itself.) People are trying to work out what > the proper fix is for userspace there when they get the time. > > So, expect the change to show up in 2.6.24. Ok. > > > > To all of this, I would like to humbly ask: > > > > > > > > PICK ONE! JUST #*%(&#%& PICK ONE! HHH! > > > > > > 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. > > What? Since when does udev have to be in the kernel source tarball? > Who ever said that? I got that impression from: http://lkml.org/lkml/2006/7/30/228 http://lwn.net/Articles/193603/ > The issue here is that if you follow the rules as specified by the file, > Documentation/sysfs-rules.txt and Documentation/ABI/*/sysfs-* you should > be just fine. To ignore them, as you have done in your examples, will > cause problems. I read the Documentation/ABI ones in the current linus -git (well, as of... tuesday?) and am unaware of any conflicts. I read sysfs-rules.txt this morning, and the only _required_ change I'm aware of is filtering out /sys/class/block if it occurs. (Is there more Documentation in Andrew Morton's tree that's not in Linus's?) Lemme re-read my document... Ok, /sys/bus/*/devices/*/dev is the path Kay told me to use during our discussion at OLS. It's one of the paths I cut and pasted out of the email he sent me. He typed that path, I didn't. I see that the bit in "sysfs-rules.txt" about never using the "devices" symlink contradicts that. Ok, so what _should_ I do? Personally, I've never seen a dev link under "/sys/bus". I neither own nor have personally encountered hardware that does that, and the first I heard that there _was_ such hardware was when talking to him at OLS. Kay: if you get this, what path should I use? Your email said: > /sys/bus/*/devices/*/dev > /sys/class/*/*/dev > /sys/block/*/dev > /sys/block/*/*/dev > > /sys/subsystem/*/devices/*/dev The fifth of which isn't in currently deployed kernels (not in kernel.org, not in most recent ubuntu release, that counts as "not currently deployed" to me),
Re: Documentation for sysfs, hotplug, and firmware loading.
On Friday 20 July 2007 8:52:11 pm Greg KH wrote: > On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote: > > > Always look at the parent devices themselves for determining device > > > context properties. > > > > For determining? > > > > What was the original language of this document? > > Ok, that's just being mean, cut it out right now if you ever want my > help again. You're right, that was uncalled for and I apologize. I got a little on edge from some of Kay's earlier comments ala: > You seem to miss the the very basic skills to collect the needed > information to do the job of documenting something. Probably combined with jetlag. I'll stop posting until I get some sleep. 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Friday 20 July 2007 4:09:36 am Greg KH wrote: > On Fri, Jul 20, 2007 at 09:54:01AM +0200, Cornelia Huck wrote: > > On Fri, 20 Jul 2007 00:00:01 -0700, > > > > Greg KH <[EMAIL PROTECTED]> wrote: > > > > 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. > > > > > > Here's the rule: > > > If the SUBSYSTEM is "block", it's a block device. Otherwise > > > it's a char device. > > > > That's actually quite confusing to the casual reader, since: > > > But also realize that the majority of events you will get have nothing > > > to do with device nodes. I think you are forgetting this fact. > > > > So the rule should be: > > If the SUBSYSTEM is "block" (implying major/minor are provided), > > it's a block device. > > If the SUBSYSTEM is not "block", and major/minor are provided, > > it's a char device. > > If major/minor are not provided, the event/device is not > > relevant to device node creation. > > Yes, that is much more descriptive, thanks. agreed, thanks. I'll try to post an updated version of my hotplug documentation later tonight. (Just a _touch_ jetlagged at the moment, though. It may only be 9:47 california time, but it's 11:47 on the east cost. I think.) > greg k-h 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote: > > Always look at the parent devices themselves for determining device > > context properties. > > For determining? > > What was the original language of this document? Ok, that's just being mean, cut it out right now if you ever want my help again. I'll gladly accept patches for this document that is in the kernel tree now if you want to send them. But criticizing the grammer of a document with statements like this one gets you no where and is damm rude. I suggest you start this thread over if you want my feedback, I'm not going to respond anymore to this one. greg k-h - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote: > I'm not trying to document /sys/devices. I'm trying to document hotplug, > populating /dev, and things like firmware loading that fall out of that. > This requires use of sysfs, and I'm only trying to document as much of sysfs > as you need to do that. Like I stated before, you do not need to even have sysfs mounted to have a dynamic /dev. And why do you need to document populating /dev dynamically? udev already solves this problem for you, it's not like people are going off and reinventing udev for their own enjoyment would not at least look at how it solves this problem first. To do otherwise would be foolish :) Firmware loading is fine to document if you wish to do so. But again, why? We already have multiple userspace programs that provide this feature for them. Perhaps you want to document how to add firmware to a system in order for these different programs to pick them up? Or perhaps you want to document how to add this kind of functionality to your kernel driver so that it can handle firmware loading by using the firmware interface that the kernel provides? If you just want to document the hotplug/uevent api, then do just that. However I think you are overreaching with your scope here and getting mighty confused in the process. thanks, greg k-h - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Fri, Jul 20, 2007 at 08:21:39PM -0400, Rob Landley wrote: > Ok, back up. /sys/devices does not contain all the information necessary to > populate /dev, because it hasn't got things like > ramdisks, /dev/zero, /dev/console which are THERE in sysfs, which may or may > not be supported by the kernel (the kernel might have ramdisk support, might > not). Welcome to 2007: $ ls /sys/devices/virtual/mem/ full kmem kmsg mem null port random urandom zero $ ls /sys/devices/virtual/tty/ console tty12 tty19 tty25 tty31 tty38 tty44 tty50 tty57 tty63 ptmx tty13 tty2 tty26 tty32 tty39 tty45 tty51 tty58 tty7 tty tty14 tty20 tty27 tty33 tty4 tty46 tty52 tty59 tty8 tty0 tty15 tty21 tty28 tty34 tty40 tty47 tty53 tty6 tty9 tty1 tty16 tty22 tty29 tty35 tty41 tty48 tty54 tty60 tty10tty17 tty23 tty3 tty36 tty42 tty49 tty55 tty61 tty11tty18 tty24 tty30 tty37 tty43 tty5 tty56 tty62 I suggest you take a close look at the kernel before making statements like the above :) > These things could also, in future, have their major and minor numbers > dynamically (even randomly) assigned. That's been discussed on this list. I tried that once, it will require some core api kernel changes and a lot of infrastrucure work to get that to work properly. Not that it will never happen in the future, but it's just not a trivial change at the moment... thanks, greg k-h - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Wednesday 18 July 2007 7:40:20 pm Greg KH wrote:
> On Wed, Jul 18, 2007 at 01:39:53PM -0400, Rob Landley wrote:
> > PICK ONE! JUST #*%(&#%& PICK ONE! HHH!
> >
> > I don't care where it is. Just put it somewhere I can find it, and keep
> > it there. All this gratuitous moving stuff around serves NO PURPOSE
> > other than to break userspace. I'm trying to document this so that the
> > next time you go "oh wait, it should be at "/sys/tarantula/fruitbat" I
> > can show that you're breaking an existing documented userspace API.
> >
> > There's a kernel config option to make symlinks from the old
> > location. /sys/block makes as much sense as any other location, and it's
> > what's there now.
>
> Read the sysfs documentation file we just added, it describes how this
> is all documented and should be used. So well that I do not think you
> need to try to document it again.
I'm not trying to document all of sysfs, I'm trying to document hotplug. I
realize now I should have been more clear about that.
I've been working on the document I just posted on and off since may,
(Possibly longer but I lost a lot of data in the hard drive crash on my
laptop last month. For example, I can't find a copy of my
half-finished "history of hotplug" document and will probably need to start
over, although I've still got a few places to look to see if I backed up a
copy...)
This document has been sitting mostly unchanged on my hard drive since OLS,
until I finally tracked down example code to do the netlink bit so I could
finish it. I tried to bounce a copy of the "everything but netlink" version
off of kay by replying to his email with notes from OLS, and that's when I
bumped into the "he's spam-blocking me" issue. It got lost in the shuffle of
OLS, and I just got back to it at the start of this thread.
Earlier today I read (and commented on, in the message to Cornelia Huck) the
copy of Documentation/sysfs-rules.txt. (Ah, darn it. I have too many open
windows on my desktop. Hits "send" on message to Cornelia huck I _wrote_
earlier today.)
Documentation/sysfs-rules.txt doesn't talk about /sbin/hotplug or netlink
hotplug. It doesn't say how to distinguish a char device from a block
device. It mostly talks about finding stuff under the "/sys/devices"
directory, most of which isn't relevant to populating /dev. It doesn't
clearly distinguish where you can find information in current kernels (2.6.22
and earlier) from stuff that hasn't gone into any existing release. Ideally
I'd like to identify a subset of that information which is not only present
in current kernels but should remain findable at that location in future
kernels. Over half the document is about what _not_ to do, and consists of
warnings about "buggy apps", despite the assumption that anything _not_
explicitly documented is forbidden because most of the things sysfs exports
are considered unmaintainable.
I've read the stuff under Documentation/ABI/{stable,testing}, and would be
happy to refer to it rather than duplicating if I could get the info I needed
out of it. Documentation/filesystems/sysfs.txt is still from Patrick Mochel
in 2003 and mostly about the kernel side rather than an API exported to
userspace, and sysfs-pci.txt in that directory is similar. Is there more I
missed?
> thanks,
>
> greg k-h
Sorry, I'm not trying to be a pain. I'm trying to document something I had to
figure out for myself experimentally in 2005, which has been broken for me by
kernel changes twice since then (when the "device" symlink went in back
around 2.6.14, and when subdirs turned to symlinks recently), and I'm told is
changing again with the additon of /sys/class/block (which means /sys/class/*
no longer contains just char devices).
Ideally I'd like to come up with documentation that allows somebody to write
one program that works on existing AND on new kernels, hence "stable API".
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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Thursday 19 July 2007 4:16:17 am Cornelia Huck wrote: > On Wed, 18 Jul 2007 13:39:53 -0400, > > Rob Landley <[EMAIL PROTECTED]> wrote: > > 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. > > I have no idea what you're doing. See the email to kay sievers. In 2.6.14 following symlinks hit an endless /sys/block/hda/device/block/device/block/device/block... This has changed since, like much of sysfs, but in the absence of either a spec or a stable API there's no guarantee it won't reoccur. > > Which is why I want it documented where to look for these suckers. Just > > give me ONE STABLE WAY TO FIND THIS INFORMATION, PLEASE. > > See Documentation/sysfs-rules.txt. Ok: Paragraph 1: "It's not stable." Paragraph 2: "It's not stable." Paragraph 3: If you really really need to access it directly... Paragraph 4: DO NOT DO $XXX. Paragraph 5: Expect it to be mounted at /sys Paragraph 6: DO NOT DO $XXX. (Specficially, the way you were distinguishing between block and char devices? Don't do that. No, we won't tell you what to replace it with, keep reading.) So far, not exactly gripping reading. Paragraph 7: What a devpath is. Ok, is it just me or does it say that applications shouldn't use the symlinks in sysfs? Why are they there, then? Paragraph 8: The kernel has a name for the device. Paragraph 9: Subsystem is a string. What it means, we leave for you to guess. Paragraph 10: Driver is the name of a driver. (Does this mean a driver is currently loaded and handling the device, or that the kernel is suggesting a driver based on something like PCI ID, through the kind of mechanism that used to be used to request module loading? Experimentally, it looks like the first, which makes sense but isn't specified. Does something like /sys/class/mem/zero or have a driver? Experimentally, no, it hasn't got a device link.) Paragraph 11: Atributes, and yet more DO NOT DO $XXX. It took me three reads of that to figure out they probably meant "Attributes belong to a device, don't confuse the attributes of another device with attributes of this device." (Following _which_ device symlink?) Ok, back up. /sys/devices does not contain all the information necessary to populate /dev, because it hasn't got things like ramdisks, /dev/zero, /dev/console which are THERE in sysfs, which may or may not be supported by the kernel (the kernel might have ramdisk support, might not). These things could also, in future, have their major and minor numbers dynamically (even randomly) assigned. That's been discussed on this list. I'm not trying to document /sys/devices. I'm trying to document hotplug, populating /dev, and things like firmware loading that fall out of that. This requires use of sysfs, and I'm only trying to document as much of sysfs as you need to do that. I'm not documenting stuff like /sys/devices/system/cpu. The consensus so far is "the udev implementation is the spec", except I watched the udev implementation change rather a lot before I stopped tracking it, and saw a number of people complain on this list about things breaking when they upgraded the kernel but not udev. Back to reading the document: > - Properties of parent devices never belong into a child device. Belong into? > Always look at the parent devices themselves for determining device > context properties. For determining? What was the original language of this document? > If the device 'eth0' or 'sda' does not have a > "driver"-link, then this device does not have a driver. Again, whether they mean "the kernel was not built with a driver that can handle this device" or "no driver is currently loaded and handling this device". It _sounds_ like "this device is not supported by Linux", which probably isn't what they meant. > Never copy any property of the parent-device into a child-device. I note that the only mention made so far of parent-child relationships in devices is in terms of "don'ts". I assume they're talking about how a partition can be the child of a block device, and a network controller card can be the child of a pci bus device? Ah, I see. The next paragraph is on hierarchy, yet doesn't actually explain anything, other than to imply that the device hierarchy being fully represented there is a dream to be achieved sometime in the future but not necessarily the truth with today's kernels, because stuff is still being _moved_ into /sys/devices. > - Classification by subsystem > There are currently three places for classification of devices: > /sys/block, /sys/class and /sys/bus. So if somebody wants to write code that runs on a current kernel, they have no alternative but to
Re: Documentation for sysfs, hotplug, and firmware loading.
On Fri, Jul 20, 2007 at 09:54:01AM +0200, Cornelia Huck wrote: > On Fri, 20 Jul 2007 00:00:01 -0700, > Greg KH <[EMAIL PROTECTED]> wrote: > > > > 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. > > > > Here's the rule: > > If the SUBSYSTEM is "block", it's a block device. Otherwise > > it's a char device. > > That's actually quite confusing to the casual reader, since: > > > But also realize that the majority of events you will get have nothing > > to do with device nodes. I think you are forgetting this fact. > > So the rule should be: > If the SUBSYSTEM is "block" (implying major/minor are provided), > it's a block device. > If the SUBSYSTEM is not "block", and major/minor are provided, > it's a char device. > If major/minor are not provided, the event/device is not > relevant to device node creation. Yes, that is much more descriptive, thanks. greg k-h - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Fri, 20 Jul 2007 00:00:01 -0700, Greg KH <[EMAIL PROTECTED]> wrote: > > 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. > > Here's the rule: > If the SUBSYSTEM is "block", it's a block device. Otherwise > it's a char device. That's actually quite confusing to the casual reader, since: > But also realize that the majority of events you will get have nothing > to do with device nodes. I think you are forgetting this fact. So the rule should be: If the SUBSYSTEM is "block" (implying major/minor are provided), it's a block device. If the SUBSYSTEM is not "block", and major/minor are provided, it's a char device. If major/minor are not provided, the event/device is not relevant to device node creation. - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Fri, Jul 20, 2007 at 01:14:27AM -0400, Rob Landley wrote: > Is there anything in /sys/class/block that _isn't_ in /sys/block? No. > 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? Ignore what? /sys/block? If you see /sys/class/block, then yes, you can ignore it as they are just symlinks back to each other. > (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. No, the /sys/class/block is in -mm and has been for some time. > 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.) Not true at all, it works just fine here on my machines, and on all distros released in the past year or so as tested out by a lot of users. The only reason it isn't in Linus's tree just yet, is that some very old mkinitrd programs don't seem to like it (we are talking Fedora Core 3 based distros, not Fedora itself.) People are trying to work out what the proper fix is for userspace there when they get the time. So, expect the change to show up in 2.6.24. > > > To all of this, I would like to humbly ask: > > > > > > PICK ONE! JUST #*%(&#%& PICK ONE! HHH! > > > > 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. What? Since when does udev have to be in the kernel source tarball? Who ever said that? The issue here is that if you follow the rules as specified by the file, Documentation/sysfs-rules.txt and Documentation/ABI/*/sysfs-* you should be just fine. To ignore them, as you have done in your examples, will cause problems. > 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. The issue is that the devices themselves keep moving around in the sysfs tree all the time as systems are dynamic and change. Again, look at the udevtrigger program for a simple way to achieve this /dev population that you so desire. But also realize that sysfs is much bigger than just trying to get the information to create a /dev tree. > > > > > 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. Here's the rule: If the SUBSYSTEM is "block", it's a block device. Otherwise it's a char device. But also realize that the majority of events you will get have nothing to do with device nodes. I think you are forgetting this fact. > 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's not a "breakage", we are preserving a symlink. The point is that you should not rely on the fact that /sys/block will be there in the future, as the documentation I pointed to above describes. > > > > 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 tota
Re: Documentation for sysfs, hotplug, and firmware loading.
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! HHH! > > 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 t
Re: Documentation for sysfs, hotplug, and firmware loading.
On Wed, 18 Jul 2007 13:39:53 -0400, Rob Landley <[EMAIL PROTECTED]> wrote: > 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. I have no idea what you're doing. > Which is why I want it documented where to look for these suckers. Just give > me ONE STABLE WAY TO FIND THIS INFORMATION, PLEASE. See Documentation/sysfs-rules.txt. > 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? That was a _suggestion_. > I know. I'm just trying to show people how to do it. Notice that this > script > doesn't DO anything, it just dumps the variables (and proves > that /sys/hotplug got called). You're worried about the scalability of a > debugging script. If you use bash scripts as examples, people will write bash scripts. > (Rummage) Seems to be "add, remove, change, online, offline, move"? > > I can list 'em. Now I'm vaguely curious what generates online and offline > events (MII transciever state transitions on a network card, or does this > have to do with power saving modes?) And I have no idea what the difference > between "change" and "move" is "change" - something about the device has changed "move" - the device is in a different position in the tree now You may want to grep for the usage... > > > > DEVPATH > > > Path under /sys at which this device's sysfs directory can be found. > > > If $DEVPATH begins with /block/ the event refers to a block device, > > > otherwise it refers to a char device. > > > > Huh? That's just the path in sysfs. And there's more than block and > > char :) Check SUBSYSTEM for what your device actually is. > > If you are doing mknod, you need three pieces of information: > 1) Major, 2) Minor, 3) Block or Char device. That's pretty much it. If > you're trying to populate /dev you need that info. > > > > SUBSYSTEM > > > If this is "block", it's a block device. Anything else is a char > > > device. > > > > No. For devices, SUBSYSTEM may be the class (like 'scsi_device') or the > > bus (like 'pci'). > > Do you make a /dev node for either one? > > I'm trying to, at minimum, document what you pass to mknod. I consider it > important to know. The problem is that your information is wrong. Imagine someone reading this document, thinking "cool, I'll create a char node if SUBSYSTEM!=block" and subsequently getting completely confused about all those SUBSYSTEM==pci events. > > > > DRIVER > > > If present, a suggested driver (module) for handling this device. No > > > relation to whether or not a driver is currently handling the device. > > > > No, this actually is the current driver. > > I've had it suggest drivers for devices that didn't have any loaded, and I > had > it _not_ specify drivers for devices that were loaded. (I checked.) The code disagrees with you. If a driver matches and probing succeeds, it will be specified, otherwise not. Maybe you were checking the wrong devices? > Ah yes. I replied to that when it was first posted. It's still "here's a > list of things NOT to do" rather then telling you what you CAN do. I'm > trying to document what you can do. > > Useful documentation is not "Doing THIS is forbidden. Doing THIS is > forbidden. Doing THIS is forbidden. What are you allowed to do? Guess! > Oh, and anything I didn't explicitly mention could change at any time. Have > fun." It _does_ specify what you may rely on. Don't rely on anything else. > Sysfs CAN export a stable API. It may only be a subset of what it's > exporting, but it can still do so. And that is exactly what sysfs-rules.txt is doing. I don't understand your problem. If you think that getting this information from sysfs-rules.txt could be made easier, do a patch against it. - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Wed, Jul 18, 2007 at 01:39:53PM -0400, Rob Landley wrote: > PICK ONE! JUST #*%(&#%& PICK ONE! HHH! > > I don't care where it is. Just put it somewhere I can find it, and keep it > there. All this gratuitous moving stuff around serves NO PURPOSE other than > to break userspace. I'm trying to document this so that the next time you > go "oh wait, it should be at "/sys/tarantula/fruitbat" I can show that you're > breaking an existing documented userspace API. > > There's a kernel config option to make symlinks from the old > location. /sys/block makes as much sense as any other location, and it's > what's there now. Read the sysfs documentation file we just added, it describes how this is all documented and should be used. So well that I do not think you need to try to document it again. thanks, greg k-h - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
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 You seem to miss the the very basic skills to collect the needed information to do the job of documenting something. To all of this, I would like to humbly ask: PICK ONE! JUST #*%(&#%& PICK ONE! HHH! Man, you totally miss the point. > > 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. > 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 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 will not reply to any of your mails until you have proven to have read the udevtrigger code, and got a clue how to do stuff reliably, and get the basic knowledge needed to document it. Kay - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Wednesday 18 July 2007 3:58:57 am Cornelia Huck wrote: > On Tue, 17 Jul 2007 17:03:31 -0400, > > Rob Landley <[EMAIL PROTECTED]> wrote: > > Here's some sysfs/hotplug/firmware loading documentation I wrote. I > > finally tracked down the netlink bits to finish it up, so I can send it > > out to the world. > > > > What's wrong with it? :) > > OK, some comments from me: > > Entires for block devices are found at the following locations: > > ^^^ typo Got it. > > /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. He never mentioned /sys/class/block. To all of this, I would like to humbly ask: PICK ONE! JUST #*%(&#%& PICK ONE! HHH! I don't care where it is. Just put it somewhere I can find it, and keep it there. All this gratuitous moving stuff around serves NO PURPOSE other than to break userspace. I'm trying to document this so that the next time you go "oh wait, it should be at "/sys/tarantula/fruitbat" I can show that you're breaking an existing documented userspace API. There's a kernel config option to make symlinks from the old location. /sys/block makes as much sense as any other location, and it's what's there now. > > 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. > 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. 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? > > A simple bash script to record variables from hotplug events might look > > like: > > Using a bash script is actually a very bad idea in the general case. It > can lead to OOM very quickly on large installations. I know. I'm just trying to show people how to do it. Notice that this script doesn't DO anything, it just dumps the variables (and proves that /sys/hotplug got called). You're worried about the scalability of a debugging script. > > It's possible to disable the usermode helper hotplug mechanism (by > > writing an empty string into /proc/sys/kernel/hotplug), but there's > > little reason to do this since a usermode helper won't be spawned if > > /sbin/hotplug doesn't exist, and negative dentries will record the fact > > it doesn't exist after the first lookup attempt. > > AFAIK, the normal mode of operation is to use the hotplug mechanism > during early setup but to disable it once you have a listener on > netlink in place. My systems have an empty /proc/sys/kernel/hotplug. And I documented how to blank it. However, lots of embedded systems stick with one mechanism because having two is something they won't waste space on. (I note that mdev is about 5k and can be made to use very little memory per instance.) Also, you can hold off on all device probing until a netlink daemon is up and then echo "add" to all the "uevent" entries you find. At one point, udev did this, dunno what it's doing now. > > ACTION > > The current hotplug action: "add" to add the device... > > [QUESTION: Full list of actions?] > > Would be good. See lib/kobject_uevent.c. Ah, I left a TODO item in there that I forgot to mark TODO. :) (Rummage) Seems to be "add, remove, change, online, offline, move"? I can list 'em. Now I'm vaguely curious what generates online and offline events (MII transciever state transitions on a network card, or does this have to do with power saving modes?) And I have no idea what the difference between "change" and "move" is > > DEVPATH > > Path under /sy
Re: Documentation for sysfs, hotplug, and firmware loading.
On Tue, 2007-07-17 at 17:03 -0400, Rob Landley wrote: > Here's some sysfs/hotplug/firmware loading documentation I wrote. I finally > tracked down the netlink bits to finish it up, so I can send it out to the > world. > > What's wrong with it? :) A lot. :) > Note, I still need to actually confirm that /sbin/hotplug can be called from > initramfs by a statically linked device to load firmware before init gets > spawned. It should work, and was explicitly discussed as a design goal a > year or two back, but it might need a bugfix patch to actually, you know, > _work_. > > (P.S. I'd cc Kay Sievers on this, but he's still spam-blocking my email. > Thanks to Kay for answer lots of questions about this at OLS, and to Fank > Sorenson who wrote a netlink implementation of mdev back in 2005 that I dug > up to figure out how that part works.) hotplug and firmware loading with sysfs. The 2.6.x Linux kernels export a device tree through sysfs, which is a synthetic filesystem generally mounted at "/sys". Among other things, this filesystem tells userspace what hardware is available, so userspace tools (such as udev or mdev) can dynamically populate a "/dev" directory with device nodes representing the currently available hardware. @@ It exposes the current state of kernel devices, it's not necessarily @@ related to any hardware. Notification when hardware is inserted or removed is provided by the hotplug mechanism. Linux provides two hotplug interfaces: /sbin/hotplug and netlink. @@ Same here, it's about kernel device creation and not hardware "insertion". The combination of sysfs and hotplug obsoleted the older "devfs", which was removed from the 2.6.16 kernel. @@ Udev replaced devfs, not hotplug or sysfs. Device nodes: = Sysfs exports major and minor numbers for device nodes with which to populate /dev via mknod(2). These major and minor numbers are found in files named "dev", which contain two colon separated ascii decimal numbers followed by exactly one newline. I.E. $ cat /sys/class/mem/zero/dev 1:5 Note that the name of the directory containing a dev entry is usually the traditional name for the device node. (The above entry is for "/dev/zero".) Entires for block devices are found at the following locations: /sys/block/*/dev /sys/block/*/*/dev Entries for char devices are found at the following locations: /sys/bus/*/devices/*/dev /sys/class/*/*/dev @@ Wrong! /sys/class/block/* will be block-devices. Please read the stuff mentioned @@ in the document Greg has posted. You _must_ always determine the subsystem. @@ This rule is plain wrong. A very simple bash script to populate /dev from /sys (without addressing ownership or permissions of the resulting /dev nodes) might look like: #!/bin/bash # Populate block devices for i in /sys/block/*/dev /sys/block/*/*/dev do if [ -f $i ] then MAJOR=$(sed 's/:.*//' < $i) MINOR=$(sed 's/.*://' < $i) DEVNAME=$(echo $i | sed -e 's@/dev@@' -e '[EMAIL PROTECTED]/@@') mknod /dev/$DEVNAME b $MAJOR $MINOR fi done # Populate char devices for i in /sys/bus/*/devices/*/dev /sys/class/*/*/dev do if [ -f $i ] then MAJOR=$(sed 's/:.*//' < $i) MINOR=$(sed 's/.*://' < $i) DEVNAME=$(echo $i | sed -e 's@/dev@@' -e '[EMAIL PROTECTED]/@@') mknod /dev/$DEVNAME c $MAJOR $MINOR fi done @@ That will fail badly. And again, please don't confuse @@ "class" and "char", they are not the same, and never have been. Hotplug: The hotplug mechanism asynchronously notifies userspace when hardware is inserted, removed, or undergoes a similar significant state change. Linux provides two interfaces to hotplug; the kernel can spawn a usermode helper process, or it can send a message to an existing daemon listening to a netlink socket. -- Usermode helper The usermode helper hotplug mechanism spawns a new process to handle each hotplug event. Each such helper process belongs to the root user (UID 0) and is a child of the init task (PID 1). The kernel spawns one process per hotplug event, supplying environment variables to each new process describing that particular hotplug event. By default the kernel spawns instances of "/sbin/hotplug", but this default can be changed by writing a new path into "/proc/sys/kernel/hotplug" (assuming /proc is mounted). @@ Are you sure it's a child of init? A simple bash script to record variables from hotplug events might look like: #!/bin/bash env >> /filename It's possible to disable the usermode helper hotplug mechanism (by writing an empty string into /proc/sys/kernel/hotplug), but there's little reason to do this since a usermode helper won't be spawned if /sbin/hotplug doesn't exist, and negative dentries will record the fact it doesn't exist after the first lookup attempt. @@ That negative dentries will exist, is no reason not to disable it. @@ Almost no s
Re: Documentation for sysfs, hotplug, and firmware loading.
On Tue, 17 Jul 2007 17:03:31 -0400, Rob Landley <[EMAIL PROTECTED]> wrote: > Here's some sysfs/hotplug/firmware loading documentation I wrote. I finally > tracked down the netlink bits to finish it up, so I can send it out to the > world. > > What's wrong with it? :) OK, some comments from me: > Entires for block devices are found at the following locations: ^^^ typo > > /sys/block/*/dev > /sys/block/*/*/dev Note that this will change to /sys/class/block/ in the future. > 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 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/). (And how about referring to Documentation/sysfs-rules.txt?) > A simple bash script to record variables from hotplug events might look like: Using a bash script is actually a very bad idea in the general case. It can lead to OOM very quickly on large installations. > It's possible to disable the usermode helper hotplug mechanism (by writing an > empty string into /proc/sys/kernel/hotplug), but there's little reason to > do this since a usermode helper won't be spawned if /sbin/hotplug doesn't > exist, and negative dentries will record the fact it doesn't exist after > the first lookup attempt. AFAIK, the normal mode of operation is to use the hotplug mechanism during early setup but to disable it once you have a listener on netlink in place. My systems have an empty /proc/sys/kernel/hotplug. > ACTION > The current hotplug action: "add" to add the device... > [QUESTION: Full list of actions?] Would be good. See lib/kobject_uevent.c. > DEVPATH > Path under /sys at which this device's sysfs directory can be found. > If $DEVPATH begins with /block/ the event refers to a block device, > otherwise it refers to a char device. Huh? That's just the path in sysfs. And there's more than block and char :) Check SUBSYSTEM for what your device actually is. > SUBSYSTEM > If this is "block", it's a block device. Anything else is a char device. No. For devices, SUBSYSTEM may be the class (like 'scsi_device') or the bus (like 'pci'). > DRIVER > If present, a suggested driver (module) for handling this device. No > relation to whether or not a driver is currently handling the device. No, this actually is the current driver. > stable_api_nonsense: > > > Note: Sysfs exports a lot of kernel internal state, and the maintainers of > sysfs do not believe that exposing information to userspace for use by > userspace programs constitues an "API" that must be "stable". The sysfs > infrastructure is maintained by the author of > Documentation/stable_api_nonsense.txt, who seems to believe it applies to > userspace as well. Therefore, at best only a subset of the information in > sysfs can be considered stable from version to version. > > The information documented here should remain stable. Some other parts > of sysfs are documented under Documentation/API, although that > directory comes with a warning that anything documented there can go > away after two years. Any other information exported by sysfs should be > considered debugging info at best, and probably shouldn't have been > exported at all since it's not a "stable API" intended for use by > actual programs. Uh. Please refer to Documentation/sysfs-rules.txt. - 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/
Re: Documentation for sysfs, hotplug, and firmware loading.
On Tue, 17 Jul 2007 17:03:31 -0400 Rob Landley wrote: > Here's some sysfs/hotplug/firmware loading documentation I wrote. I finally > tracked down the netlink bits to finish it up, so I can send it out to the > world. > > What's wrong with it? :) (1. It's an attachment. :) 2. Here's a C program to print hotplug nelink events to stdout: s/nelink/netlink/ 3. See Documentation/firmware_class for more information. Perhaps add a '/' after "firmware_class" to indicate a directory? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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/
Documentation for sysfs, hotplug, and firmware loading.
Here's some sysfs/hotplug/firmware loading documentation I wrote. I finally
tracked down the netlink bits to finish it up, so I can send it out to the
world.
What's wrong with it? :)
Note, I still need to actually confirm that /sbin/hotplug can be called from
initramfs by a statically linked device to load firmware before init gets
spawned. It should work, and was explicitly discussed as a design goal a
year or two back, but it might need a bugfix patch to actually, you know,
_work_.
(P.S. I'd cc Kay Sievers on this, but he's still spam-blocking my email.
Thanks to Kay for answer lots of questions about this at OLS, and to Fank
Sorenson who wrote a netlink implementation of mdev back in 2005 that I dug
up to figure out how that part works.)
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
hotplug and firmware loading with sysfs.
The 2.6.x Linux kernels export a device tree through sysfs, which is a
synthetic filesystem generally mounted at "/sys". Among other things,
this filesystem tells userspace what hardware is available, so userspace tools
(such as udev or mdev) can dynamically populate a "/dev" directory with device
nodes representing the currently available hardware.
Notification when hardware is inserted or removed is provided by the
hotplug mechanism. Linux provides two hotplug interfaces: /sbin/hotplug and
netlink.
The combination of sysfs and hotplug obsoleted the older "devfs", which was
removed from the 2.6.16 kernel.
Device nodes:
=
Sysfs exports major and minor numbers for device nodes with which to populate
/dev via mknod(2). These major and minor numbers are found in files named
"dev", which contain two colon separated ascii decimal numbers followed by
exactly one newline. I.E.
$ cat /sys/class/mem/zero/dev
1:5
Note that the name of the directory containing a dev entry is usually the
traditional name for the device node. (The above entry is for "/dev/zero".)
Entires for block devices are found at the following locations:
/sys/block/*/dev
/sys/block/*/*/dev
Entries for char devices are found at the following locations:
/sys/bus/*/devices/*/dev
/sys/class/*/*/dev
A very simple bash script to populate /dev from /sys (without addressing
ownership or permissions of the resulting /dev nodes) might look like:
#!/bin/bash
# Populate block devices
for i in /sys/block/*/dev /sys/block/*/*/dev
do
if [ -f $i ]
then
MAJOR=$(sed 's/:.*//' < $i)
MINOR=$(sed 's/.*://' < $i)
DEVNAME=$(echo $i | sed -e 's@/dev@@' -e '[EMAIL PROTECTED]/@@')
mknod /dev/$DEVNAME b $MAJOR $MINOR
fi
done
# Populate char devices
for i in /sys/bus/*/devices/*/dev /sys/class/*/*/dev
do
if [ -f $i ]
then
MAJOR=$(sed 's/:.*//' < $i)
MINOR=$(sed 's/.*://' < $i)
DEVNAME=$(echo $i | sed -e 's@/dev@@' -e '[EMAIL PROTECTED]/@@')
mknod /dev/$DEVNAME c $MAJOR $MINOR
fi
done
Hotplug:
The hotplug mechanism asynchronously notifies userspace when hardware is
inserted, removed, or undergoes a similar significant state change. Linux
provides two interfaces to hotplug; the kernel can spawn a usermode helper
process, or it can send a message to an existing daemon listening to a netlink
socket.
-- Usermode helper
The usermode helper hotplug mechanism spawns a new process to handle each
hotplug event. Each such helper process belongs to the root user (UID 0) and
is a child of the init task (PID 1). The kernel spawns one process per hotplug
event, supplying environment variables to each new process describing that
particular hotplug event. By default the kernel spawns instances of
"/sbin/hotplug", but this default can be changed by writing a new path into
"/proc/sys/kernel/hotplug" (assuming /proc is mounted).
A simple bash script to record variables from hotplug events might look like:
#!/bin/bash
env >> /filename
It's possible to disable the usermode helper hotplug mechanism (by writing an
empty string into /proc/sys/kernel/hotplug), but there's little reason to
do this since a usermode helper won't be spawned if /sbin/hotplug doesn't
exist, and negative dentries will record the fact it doesn't exist after
the first lookup attempt.
-- Netlink
A daemon listening to the netlink socket receives a packet of data for each
hotplug event, containing the same information a usermode helper would receive
in environment variables.
The netlink packet contains a set of null terminated text lines.
Each line but the first contains a KEYWORD=VALUE pair defining a hotplug
event variable. The first line of the netlink packet combines the $ACTION
and $DEVPATH values, separated by an @ (at sign).
Here's a C program to print hotplug nelink events to stdout:
#include
#include
#include
#include
#include
#include
#include
#include
#include
void die(char *s)
{
write(2,s,strlen(s));
e
