State of devfs in 2.6?
Whats the general feeling about devfs now? I remember Christoph and others making some nasty remarks about it 6months ago or so, but later noted christoph doing some slashing and burning thereof.
Is it 'nice' yet?
Andrew Walrond
Quoted 5 lines · Andrew Walrond
Whats the general feeling about devfs now? I remember Christoph and others making some nasty remarks about it 6months ago or so, but later noted christoph doing some slashing and burning thereof.
Is it 'nice' yet?
Andrew Walrond
I would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism.
-- wli
Quoted 5 lines · William Lee Irwin III
I would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism.
Thanks for the pointer.
So how good is the device coverage offered by sysfs/udev ? Do they provide a viable/complete MAKEDEV replacement yet?
Quoted 3 lines · Andrew Walrond
So how good is the device coverage offered by sysfs/udev ? Do they provide a viable/complete MAKEDEV replacement yet?
It works for me on my laptop :)
You might have different devices and need other things. If so, please let me know after trying it out.
greg k-h
My initial query has thrown up lots of interesting debate :)
I, like most people I suspect, love the concept of a complete auto-populated dev directory, and not having to MAKEDEV.
devfs provided this, but like most people who read LKML, I stopped using it when it's problems were discussed.
I really hope udev lives up to its promise, unlike devfs. Manually creating / dev just annoys me for no apparent reason other than it's plain inelegance I suppose.
Andrew Walrond
Quoted 4 lines · Andrew Walrond
My initial query has thrown up lots of interesting debate :)
I, like most people I suspect, love the concept of a complete auto-populated dev directory, and not having to MAKEDEV.
So do I.
Quoted 6 lines
devfs provided this, but like most people who read LKML, I stopped using it when it's problems were discussed.
I really hope udev lives up to its promise, unlike devfs. Manually creating / dev just annoys me for no apparent reason other than it's plain inelegance I suppose.
Does anyone else remember all the talk about the supreme elegance of devfs back when it was new?
Signature · 2 lines
Måns Rullgård [email protected]
Replying to Andrew Walrond:
Quoted 11 lines
My initial query has thrown up lots of interesting debate :)
I, like most people I suspect, love the concept of a complete auto-populated dev directory, and not having to MAKEDEV.
devfs provided this, but like most people who read LKML, I stopped using it when it's problems were discussed.
I really hope udev lives up to its promise, unlike devfs. Manually creating / dev just annoys me for no apparent reason other than it's plain inelegance I suppose.
The one of main benefits I considered when focusing my attention on devfs-like approach is space consumption. Somewhat-populated dev subdirectory (looking at fedora 1) have about 7k items inside, each of them eating its inode and (depends on underlying fs) a block.
I agree that previous implementation may be racy, domb, gooched, whatever.
but
is it sane that for system to function correcly I should carry over a whole bunch of directory entries, when I actually have all information about it in kernel, somewhere buried under major-minor declarations.
That is, udev backed on tmpfs approach are almost
solving our problem. But not completely. Module autoloading is useful, actually, was useful in conjunction with module unloading - if unloading support is poor autoloading is almost useless ...
Signature · 2 lines
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head
Quoted 9 lines · Andrew Walrond
Quoted 3 lines · William Lee Irwin III
I would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism.
Thanks for the pointer.
So how good is the device coverage offered by sysfs/udev ? Do they provide a viable/complete MAKEDEV replacement yet?
My understanding is that udev takes the information exported by sysfs about what devices exist in the system, and creates device nodes in /dev (which can be a ramfs mount or part of a persistent filesystem, udev itself doesn't care). I'm guessing it traverses sysfs to see what the system's got on startup (some variant of "find /sys -name device", perhaps) and then receives hotplug events when new devices are added later. On the whole, this is generally cool, hotplug friendly, and small and simple. _and_ the result looks like a recognizable /dev directory, so end-user applications don't have to be "devfs aware" (which was a bad sign from day 1 if you ask me).
Unfortunately, sysfs doesn't yet export device node information for everything in the system yet. (There aren't any under /sys/cdev, /sys/devices/legacy, or /sys/devices/system, for example). There are pending patches to add more, but they're not considered bug fixes, so Linus won't take them before 2.6.0 and we'll have to wait until after 2.6.0 for development on this subsystem to finish.
Probably somewhere in the 2.6.4 to 2.6.6 timeframe, sysfs will have all the device exports udev needs. (Or at least all the ones anybody's complained about yet.) Until then... dunno. Maybe you can use a /dev directory on a persistent filesystem that you mknod any extra devices you need into yourself?)
Rob
udev sysfs docs Re: State of devfs in 2.6?
In reply to William Lee Irwin IIIQuoted 8 lines · William Lee Irwin III
Quoted 4 lines · Andrew Walrond
Whats the general feeling about devfs now? I remember Christoph and others making some nasty remarks about it 6months ago or so, but later noted christoph doing some slashing and burning thereof. Is it 'nice' yet? Andrew Walrond
Quoted 7 lines
I would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism.
-- wli
Where can we find documentation on sysfs and udev, and on transition issues? I know devfs hasn't been maintained for a long time but the documentation for it comes with kernel source and there it is in menuconfig. Every time I hear that udev and sysfs replace devfs I wonder where to pick up the thread, where is that doc, where is the menuconfig option ;-) I guess there is a website but to bring people out of devfs with their /etc/devfs/compat_symlinks necessary to boot so they will have to manually make edits, it would be necessary to research the manual edits it takes to boot (md0 vs. md/0, tty vs. vc, etc., /etc/inittab, maybe etc pam or security ).
If transitioning from devfs to udev sysfs comes down to one mistake so I can't boot and have to lilo
append="rw init=/bin/bash" and edit /etc/innitab
then I need the doc on boot partition to make the last edits to transition completely and save myself (not docs on a website). Shouldn't udev sysfs doc come with kernel source(maybe it does!?)?
-Bob
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 18 lines · Bob
Quoted 16 lines · William Lee Irwin III
Quoted 7 lines · Andrew Walrond
Whats the general feeling about devfs now? I remember Christoph and others making some nasty remarks about it 6months ago or so, but later noted christoph doing some slashing and burning thereof.
Is it 'nice' yet?
Andrew WalrondI would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism.
Quoted 4 lines
Quoted 2 lines
-- wli
Where can we find documentation on sysfs and udev, and on transition issues?
Oh come on, google for "udev FAQ". It's been posted here a number of times...
Quoted 3 lines
I know devfs hasn't been maintained for a long time but the documentation for it comes with kernel source and there it is in menuconfig.
udev is a user program, and it's documentation is not in the kernel tree. It's within the source of udev, and is quite extensive.
Quoted 3 lines
Every time I hear that udev and sysfs replace devfs I wonder where to pick up the thread, where is that doc, where is the menuconfig option ;-)
There is neither. You always get sysfs in 2.6, and udev is a user program. No kernel options to enable (well, you do need CONFIG_HOTPLUG enabled I guess...)
Please read the udev docs and FAQ, it is there for a reason.
greg k-h
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 14 lines · On Mon, 8 Dec 2003 15:37:55 -0800 Greg KH <[email protected]> wrote:
Quoted 13 lines · Bob
Quoted 11 lines · William Lee Irwin III
Quoted 1 line · Andrew Walrond
Whats the general feeling about devfs now? I remember Christoph
and >others making some nasty remarks about it 6months ago or so, but later >noted christoph doing some slashing and burning thereof.
Quoted 4 lines
Is it 'nice' yet?
Andrew Walrond
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
I would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism.
From the udev FAQ:
Q: But udev will not automatically load a driver if a /dev node is opened
when it is not present like devfs will do.
A: If you really require this functionality, then use devfs. It is still
present in the kernel.
Will it have this 'equivalent functionality' some day?
Signature · 1 line
Jabber: [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 35 lines · Witukind
Quoted 29 lines · On Mon, 8 Dec 2003 15:37:55 -0800 Greg KH <[email protected]> wrote:
Quoted 26 lines · Bob
Quoted 22 lines · William Lee Irwin III
Quoted 3 lines · Andrew Walrond
Whats the general feeling about devfs now? I remember Christoph
and >others making some nasty remarks about it 6months ago or so, but later >noted christoph doing some slashing and burning thereof.
Quoted 5 lines
Is it 'nice' yet? Andrew Walrond
I would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism.
Quoted 12 lines
Quoted 1 line
From the udev FAQ:
Q: But udev will not automatically load a driver if a /dev node is opened
when it is not present like devfs will do.
A: If you really require this functionality, then use devfs. It is still
present in the kernel.Will it have this 'equivalent functionality' some day?
Shouldn't hotplug handle it?
hotplug and udev and sysfsutils are together at
http://www.kernel.org/pub/linux/utils/kernel/hotplug
so hotplug is part of the sysfs and udev program.
-Bob D
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 9 lines · Bob
Quoted 7 lines · Witukind
From the udev FAQ:
Q: But udev will not automatically load a driver if a /dev node is opened
when it is not present like devfs will do.
A: If you really require this functionality, then use devfs. It is still
present in the kernel.
Quoted 6 lines
Quoted 5 lines
Will it have this 'equivalent functionality' some day?
Shouldn't hotplug handle it?
How would hotplug handle it?
Or, more directly ... on my system, /dev is just a normal directory on an ext2 filesystem. If something tries to open a file on it that doesn't exist, open will just return ENOENT. How is open supposed to know that someone is trying to open a device node? The naive solution is to conditionally check for the presence of "/dev" at the beginning of all requested filenames that don't exist, which strikes me as ... well, not necessarily a good idea. (I can't really say why beyond gut feeling.)
My guess is, unfortunately, udev probably won't handle this any time soon. (Or, if it does, through some possibly clever mechanism that, as someone unfamiliar with the relevant bits of the system, I can't see.) I'd be interested in a solution to this, mostly out of curiosity since it seems like it might be interesting, but I don't see a nice one coming easily. I wouldn't mind someone more clueful telling me I'm wrong, though. At the least, it means more people being receptive to moving to udev.
Matt
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 8 lines · Matthew Reppert
Quoted 8 lines
Quoted 8 lines
From the udev FAQ:
Q: But udev will not automatically load a driver if a /dev node is opened
when it is not present like devfs will do.
A: If you really require this functionality, then use devfs. It is still
present in the kernel.Will it have this 'equivalent functionality' some day?
That's one thing I like about devfs.
Quoted 4 lines
Quoted 1 line
Shouldn't hotplug handle it?
How would hotplug handle it?
Quoted 8 lines
Or, more directly ... on my system, /dev is just a normal directory on an ext2 filesystem. If something tries to open a file on it that doesn't exist, open will just return ENOENT. How is open supposed to know that someone is trying to open a device node? The naive solution is to conditionally check for the presence of "/dev" at the beginning of all requested filenames that don't exist, which strikes me as ... well, not necessarily a good idea. (I can't really say why beyond gut feeling.)
One solution could be to make new virtual fs, say udevfs, which would be tmpfs, plus it would run modprobe when you try to open missing files. Then again, maybe I've missed something that makes this a bad idea.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Matthew ReppertQuoted 4 lines · Matthew Reppert
My guess is, unfortunately, udev probably won't handle this any time soon. (Or, if it does, through some possibly clever mechanism that, as someone unfamiliar with the relevant bits of the system, I can't see.)
udev will never handle it. That's not its job.
Quoted 5 lines
I'd be interested in a solution to this, mostly out of curiosity since it seems like it might be interesting, but I don't see a nice one coming easily. I wouldn't mind someone more clueful telling me I'm wrong, though. At the least, it means more people being receptive to moving to udev.
Solution for a problem that is non-existant on a properly configured system? Why? :)
greg k-h
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 8 lines · Greg KH
Quoted 5 lines
I'd be interested in a solution to this, mostly out of curiosity since it seems like it might be interesting, but I don't see a nice one coming easily. I wouldn't mind someone more clueful telling me I'm wrong, though. At the least, it means more people being receptive to moving to udev.
Solution for a problem that is non-existant on a properly configured system? Why? :)
Apparently, there are people that want the functionality. Besides, why was it introduced in the first place, if not as a solution to some problem or other?
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to BobQuoted 4 lines · Bob
hotplug and udev and sysfsutils are together at
http://www.kernel.org/pub/linux/utils/kernel/hotplug
so hotplug is part of the sysfs and udev program.
No.
udev uses the /sbin/hotplug notifier to do its work.
udev uses libsysfs (what is under sysfsutils) to access sysfs easier, instead of making me muck around in sysfs directly. sysfsutils has nothing to do with /sbin/hotplug.
greg k-h
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Bobmaybe add this to the faq?
Q: devfs did load drivers when someone tried to open() a non existing device. will sysfs/hotplug/udev do this?
A: there is no need to. hotplug/sysfs/udev will create devices for all hardware supported by the kernel and the available modules. it will do that during boot up, and whenever new hardware is added. so you can expect all devices be already present, no need for a devfs like mechanism.
Q: but what if a device is still missing?
A: in that case neither the linux kernel nor the available modules support that hardware, so there is nothing hotplug/sysfs/udev can do about it. If you add modules and [FIXME: how to update the module maps] and [FIXME: remove and attach again or do ... to spawn hotplug events] the kernel will load the modules and udev will create the device files.
Andreas
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 6 lines · Andreas Jellinghaus
maybe add this to the faq?
Q: devfs did load drivers when someone tried to
open()a non existing device. will sysfs/hotplug/udev do this?A: there is no need to.
I never like it when the answer is "you don't want to do this". It makes me think of a certain Redmond based company.
Quoted 4 lines
hotplug/sysfs/udev will create devices for all hardware supported by the kernel and the available modules. it will do that during boot up, and whenever new hardware is added. so you can expect all devices be already present, no need for a devfs like mechanism.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 11 lines · Måns Rullgård
Quoted 6 lines · Andreas Jellinghaus
maybe add this to the faq?
Q: devfs did load drivers when someone tried to
open()a non existing device. will sysfs/hotplug/udev do this?A: there is no need to.
I never like it when the answer is "you don't want to do this". It makes me think of a certain Redmond based company.
ok, rephrase:
A: all drivers are already loaded via the hotplug mechanism, and sysfs/udev did create the device. If it is still missing, you don't have drivers for your hardware.
better?
Andreas
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Måns RullgårdQuoted 5 lines · Måns Rullgård
Quoted 2 lines · Andreas Jellinghaus
maybe add this to the faq?
Quoted 16 lines
Quoted 4 lines
Q: devfs did load drivers when someone tried to
open()a non existing device. will sysfs/hotplug/udev do this?A: there is no need to.
I never like it when the answer is "you don't want to do this". It makes me think of a certain Redmond based company.
Quoted 4 lines
hotplug/sysfs/udev will create devices for all hardware supported by the kernel and the available modules. it will do that during boot up, and whenever new hardware is added. so you can expect all devices be already present, no need for a devfs like mechanism.
No... that's MacOS.. it does everything you want it to do... if you think otherwise, you're *wrong*, although this isn't as applicable in MacOS X...
--Oliver
PS not meant to offend MacOS users...
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 9 lines · Oliver Hunt
Quoted 7 lines · Måns Rullgård
Quoted 5 lines · Andreas Jellinghaus
maybe add this to the faq?
Q: devfs did load drivers when someone tried to
open()a non existing device. will sysfs/hotplug/udev do this?
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
A: there is no need to.
I never like it when the answer is "you don't want to do this". It makes me think of a certain Redmond based company.
No... that's MacOS.. it does everything you want it to do... if you think otherwise, you're *wrong*,
Quite true, I've never been able to use the old MacOS for more than a few minutes without a total system crash, only fixable by pulling the plug. MacOS is right, I don't want to use it, and it didn't let me. Perfect.
Quoted 1 line
although this isn't as applicable in MacOS X...
It didn't crash, but it made me log out very quickly.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 4 lines · Måns Rullgård
Quite true, I've never been able to use the old MacOS for more than a few minutes without a total system crash, only fixable by pulling the plug. MacOS is right, I don't want to use it, and it didn't let me. Perfect.
you need almost 4 lines to say 'I should better not use a computer.'?
Signature · 3 lines
USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Måns RullgårdQuoted 30 lines · Måns Rullgård
Quoted 11 lines · Oliver Hunt
Quoted 8 lines · Måns Rullgård
Quoted 5 lines · Andreas Jellinghaus
maybe add this to the faq?
Q: devfs did load drivers when someone tried to
open()a non existing device. will sysfs/hotplug/udev do this?Quoted 8 lines
Quoted 5 lines
Quoted 1 line
A: there is no need to.
I never like it when the answer is "you don't want to do this". It makes me think of a certain Redmond based company.
No... that's MacOS.. it does everything you want it to do... if you think otherwise, you're *wrong*,
Quite true, I've never been able to use the old MacOS for more than a few minutes without a total system crash, only fixable by pulling the plug. MacOS is right, I don't want to use it, and it didn't let me. Perfect.
Quoted 5 lines
Quoted 1 line
although this isn't as applicable in MacOS X...
It didn't crash, but it made me log out very quickly.
I'm currently doing development under macos x, and have come to the conclusion that macos does some things well, others, not so well... There's certainly a lot that can be learned from it (sometimes we can learn what not to do -- The dock would be a good example of this :) )
--Oliver
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 4 lines · Oliver Hunt
Quoted 2 lines · Måns Rullgård
Oliver Hunt <[email protected]> writes:
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
although this isn't as applicable in MacOS X...
It didn't crash, but it made me log out very quickly.
I'm currently doing development under macos x, and have come to the conclusion that macos does some things well, others, not so well... There's certainly a lot that can be learned from it (sometimes we can learn what not to do -- The dock would be a good example of this :) )
MacOS X is much better than the earlier ones, if you get rid if the terrible GUI, that is. The file manager wouldn't even let me see /tmp, or a whole lot of other files. I tried to burn a CD-RW, but that failed. The problem was it already had some files on it, so macos kindly mounted it for me, and then refused to write erase a mounted disk. Enough of this ranting, though. It's off-topic.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to WitukindQuoted 8 lines · Witukind
From the udev FAQ:
Q: But udev will not automatically load a driver if a /dev node is opened
when it is not present like devfs will do.
A: If you really require this functionality, then use devfs. It is still
present in the kernel.Will it have this 'equivalent functionality' some day?
Heh, no. I really don't believe all of the people who keep asking me this. I think I need to reword this answer to something like:
A: That is correct. If you really require this functionality, then
use devfs. There is no way that udev can support this, and it never will.
That better? :)
thanks,
greg k-h
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 3 lines · Greg KH
A: That is correct. If you really require this functionality, then
use devfs. There is no way that udev can support this, and it never will.
That's something I don't understand: I thought that with a well configured hotplug+udev system, you'll never have to worry about loading drivers on device-node open() because all drivers should be auto-loaded and all device-nodes should be auto-created.
Am I wrong ?
Xav
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 11 lines · Xavier Bestel
Quoted 3 lines · Greg KH
A: That is correct. If you really require this functionality, then
use devfs. There is no way that udev can support this, and it never will.That's something I don't understand: I thought that with a well configured hotplug+udev system, you'll never have to worry about loading drivers on device-node
open()because all drivers should be auto-loaded and all device-nodes should be auto-created.Am I wrong ?
No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either.
thanks,
greg k-h
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 11 lines · Greg KH
Quoted 8 lines
Quoted 3 lines
A: That is correct. If you really require this functionality, then
use devfs. There is no way that udev can support this, and it never will.That's something I don't understand: I thought that with a well configured hotplug+udev system, you'll never have to worry about loading drivers on device-node
open()because all drivers should be auto-loaded and all device-nodes should be auto-created.No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either.
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
-Miles
Signature · 2 lines
P.S. All information contained in the above letter is false,
for reasons of military security.Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 9 lines · Miles Bader
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
A: That is correct. If you really require this functionality, then
use devfs. There is no way that udev can support this, and it never will.That's something I don't understand: I thought that with a well configured hotplug+udev system, you'll never have to worry about loading drivers on device-node
open()because all drivers should be auto-loaded and all device-nodes should be auto-created.
Quoted 5 lines
Quoted 2 lines
No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either.
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
I believe the original motivation for module autoloading was to save memory by unloading modules when their devices were unused. Loading them automatically on demand made for less trouble for users, who didn't have to run modprobe manually to use the sound card, or whatever. This could still be a good thing in embedded systems.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 19 lines · Måns Rullgård
Quoted 9 lines · Miles Bader
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
A: That is correct. If you really require this functionality, then
use devfs. There is no way that udev can support this, and it never will.That's something I don't understand: I thought that with a well configured hotplug+udev system, you'll never have to worry about loading drivers on device-node
open()because all drivers should be auto-loaded and all device-nodes should be auto-created.Quoted 5 lines
Quoted 2 lines
No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either.
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
Quoted 6 lines
I believe the original motivation for module autoloading was to save memory by unloading modules when their devices were unused. Loading them automatically on demand made for less trouble for users, who didn't have to run modprobe manually to use the sound card, or whatever. This could still be a good thing in embedded systems.
Sure.
And if you want to run this way with udev, set it up so device nodes don't get deleted when the device unloads. That way you keep device nodes for your driverless devices, and when you try to open them the kernel runs modprobe for you. Devfs isn't needed for that afaik, it is only needed for modprobing devices that doesn't have a /dev entry yet.
Your /dev will contain nodes both for driven and non-driven devices, but not for devices you don't have at all.
Helge Hafting
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 9 lines · Helge Hafting
And if you want to run this way with udev, set it up so device nodes don't get deleted when the device unloads. That way you keep device nodes for your driverless devices, and when you try to open them the kernel runs modprobe for you. Devfs isn't needed for that afaik, it is only needed for modprobing devices that doesn't have a /dev entry yet.
Your /dev will contain nodes both for driven and non-driven devices, but not for devices you don't have at all.
If anyone wants to do this _properly_, this is what to do:
1. Let hotplug+udev load modules and create devices as they do now.
2. Keep track of when devices are used, and when they are not busy. We already have this, it's the module reference count.
3. When a device has not been used in a while, convert it to an "inactive" state. In this state, the hardware device is made quiescent and interrupt handlers are unregistered (perhaps temporarily; the interrupt might still be claimed, but the handler must not be called).
The power management hooks should be involved, as this is an ideal opportunity to power down a device to a low-power or off state, just like during APM/ACPI suspend.
4. Make module code pages _demand-pagable_ from the original place where the module was loaded when all devices using the module are in the inactive state.
This forces the module file to be kept open, so demand paging may be optionally disabled allowing the underlying fs to be unmounted.
This will create all the correct device entries for hardware which is permanent or plugged in whether used or not; it will remove device entries for hardware which is unplugged; it will retain state across device opens, and it will save memory.
The traditional problems with making module code swappable are that swapping is not safe in critical sections like interrupt handlers, and you never know which modules are needed for swapping. The former is solved by locking the code in RAM while the devices are active and have registered interrupt handlers (or other callbacks). The latter is obviously likely with the IDE or filesystem modules, but what if I'm swapping over a multi-route network where the backup link is on-demand PPP over a software modem over my ALSA driven radio card?
That last problem is not solved in general by the current /etc/modprobe.conf method of loading whole modules on demand. However any system which works with whole module demand loading, and several more, will work automatically with demand-paged modules.
A demand-paged module retains a reference to the filesystem it is mounted on, and it may be generally assumed that the filesystem will stay accessible e.g. as a local disk, boot-time accessible NFS, initramfs, or even an embedded ROM.
If the filesystem's underlying device or network is dependent on a module, the mount reference will ensure that device cannot enter the inactive state, so the situation of a module being paged out which is needed to page it back in won't arise, except in the most contrived situations such as modules being loaded over NFS over an on-demand network link. Even then, the failure case is well confined: the kernel's attempt to make a device "active" will fail in userspace at the point where it tried to open the device, configure the network interface or whatever else would cause a module to be demand loaded.
Now that the kernel parses ELF module files itself, this idea is much more feasible than it once was.
-- Jamie
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 2 lines
2. Keep track of when devices are used, and when they are not busy. We already have this, it's the module reference count.
USB modules (eg: xxxx-hcd) are typically set up so they can be unloaded at any
time: the act of unloading disconnects any devices driven by the module and frees resources. I guess this is problematic for your point 2. I understand that some network modules work this way too.
All the best,
Duncan.
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 8 lines · Duncan Sands
Quoted 2 lines
2. Keep track of when devices are used, and when they are not busy. We already have this, it's the module reference count.
USB modules (eg: xxxx-hcd) are typically set up so they can be unloaded at any time: the act of unloading disconnects any devices driven by the module and frees resources. I guess this is problematic for your point 2. I understand that some network modules work this way too.
I don't see a problem. A HCD device such as a keyboard is always "active" because it must always be listening for keys as long as the keyboard is plugged in. You can explicitly "soft unplug" by unloading the module; the proposal doesn't change that. (Although it would be a nice interface to copy the PCMCIA method, where you tell the USB subsystem to disconnect a device instead of having to know which module(s) to unload).
I agree that in that case, the device is active regardless of its module reference count. They aren't the same thing.
(Taking it further, USB keyboard is an example of a driver that could be made permanently demand-pageable as all of the code _could_ be executed in a process context, if USB's callbacks were made to work that way, but that road is potentially quite a complicated and error prone one).
A network device is similar as long as its interface is up (if it's a device). A protocol module is active as long as it has any active users, for which various definitions are possible.
Protocol (+ mid-layer, helper modules etc.) show that ideally the "active" property of a module includes any references to it by other active modules, which can be interpreted in a simple or a complicated way, depending on how thoroughly you want modules to be paged out while still presenting their interfaces in /sys, /dev, /proc, ifconfig, iptables etc.
-- Jamie
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Jamie LokierQuoted 3 lines · Jamie Lokier
If anyone wants to do this _properly_, this is what to do:
I might have missed something, but this is only for modular devices right? No application to devices compiled in monolithically?
Is there already in place similar functionality for non-modules?
-chuck
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 7 lines · Chuck Campbell
Quoted 3 lines · Jamie Lokier
If anyone wants to do this _properly_, this is what to do:
I might have missed something, but this is only for modular devices right?
Depends on what you mean by "this".
Quoted 1 line
No application to devices compiled in monolithically?
As devices are detected, hotplug is called (which then calls udev), and udev finds the new entries in /sys and adds the appropriate nodes in /dev. Completely separate from udev, the hotplug framework also loads the module if the driver is not compiled-in.
Chris
Signature · 4 lines
Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Chuck CampbellPlease, don't CC me. I'm subscribed to linux-kernel and don't need two copies of all mails.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 2 lines · [email protected] (Måns Rullgård) writes:
Please, don't CC me. I'm subscribed to linux-kernel and don't need two copies of all mails.
You ought to put in one of those magic headers that says so (I don't see one in your messages, though maybe I overlooked something), as you can hardly expect everybody to remember who's subscribed to the list and who's not.
[No I don't remember what they are; I don't care about duplicate replies, in fact I _like_ duplicate replies (because it means I usually get a copy faster than what goes through the list reflector).]
-Miles
Signature · 1 line
We live, as we dream -- alone....
Re: udev sysfs docs Re: State of devfs in 2.6?
Miles Bader <[email protected]> said on 15 Dec 2003 11:12:50 +0900:
Quoted 4 lines
Quoted 2 lines · [email protected] (Måns Rullgård) writes:
Please, don't CC me. I'm subscribed to linux-kernel and don't need two copies of all mails.
Quoted 8 lines
You ought to put in one of those magic headers that says so (I don't see one in your messages, though maybe I overlooked something), as you can hardly expect everybody to remember who's subscribed to the list and who's not.
[No I don't remember what they are; I don't care about duplicate replies, in fact I _like_ duplicate replies (because it means I usually get a copy faster than what goes through the list reflector).]
And there's always procmail:
# avoid duplicate messages :0 Whc: msgid.lock | formail -D 16384 .msgid.cache
:0 a:
.duplicates
I do further processing to make sure that any replies direct to me make it direct to me, instead of going into mailing list folder...
Signature · 3 lines
TimC -- http://astronomy.swin.edu.au/staff/tconnors/ "Eddies in the space time continuum" "Oh. Is he?" -- Zem?
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Miles BaderQuoted 7 lines · Miles Bader
Quoted 2 lines · [email protected] (Måns Rullgård) writes:
Please, don't CC me. I'm subscribed to linux-kernel and don't need two copies of all mails.
You ought to put in one of those magic headers that says so (I don't see one in your messages, though maybe I overlooked something), as you can hardly expect everybody to remember who's subscribed to the list and who's not.
I am also a believer that it is the sender's responsibility to communicate their wishes according to the generally accepted protocols.
At the moment, I believe the most popular and implemented one is Mail-Followup-To. Set it however you want. Don't complain until you have set it.
This is standard mailing list trivia, though, and so, please keep "don't CC me requests" off the mailing list. :-)
My excuse for posting this is to offer Mail-Followup-To as a researching starting point, rather than let people become frustrated.
Cheers,
mark
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Måns RullgårdQuoted 9 lines · On Tue, 09 Dec 2003 10:39:32 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 2 lines
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
I believe the original motivation for module autoloading was to save memory by unloading modules when their devices were unused. Loading them automatically on demand made for less trouble for users, who didn't have to run modprobe manually to use the sound card, or whatever. This could still be a good thing in embedded systems.
I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea.
Signature · 1 line
Jabber: [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 12 lines · Witukind
Quoted 9 lines · On Tue, 09 Dec 2003 10:39:32 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 2 lines
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
I believe the original motivation for module autoloading was to save memory by unloading modules when their devices were unused. Loading them automatically on demand made for less trouble for users, who didn't have to run modprobe manually to use the sound card, or whatever. This could still be a good thing in embedded systems.
Quoted 2 lines
I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea.
The biggest modules are about 100k. Saving 100k of 1 GB doesn't really seem worth any effort.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 14 lines · On Wed, 10 Dec 2003 20:33:24 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 12 lines · Witukind
Quoted 4 lines · On Tue, 09 Dec 2003 10:39:32 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 2 lines
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
I believe the original motivation for module autoloading was to
save> memory by unloading modules when their devices were unused. Loading> them automatically on demand made for less trouble for users, who> didn't have to run modprobe manually to use the sound card, or> whatever. This could still be a good thing in embedded systems.>
Quoted 5 lines
Quoted 2 lines
I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea.
The biggest modules are about 100k. Saving 100k of 1 GB doesn't really seem worth any effort.
I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k is worth the effort.
Signature · 1 line
Jabber: [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 13 lines · Witukind
Quoted 9 lines · On Wed, 10 Dec 2003 20:33:24 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 6 lines · Witukind
Quoted 3 lines · On Tue, 09 Dec 2003 10:39:32 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 2 lines
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
I believe the original motivation for module autoloading was to
save> memory by unloading modules when their devices were unused. Loading> them automatically on demand made for less trouble for users, who> didn't have to run modprobe manually to use the sound
card, or> whatever. This could still be a good thing in embedded
systems.>
the biggest advantage from modules is the ability to enable/disable devices with different initialization configurations without rebooting, including the use of devices that aren't present during boot or may be added to a system that cant be put down to reboot. Embedded systems usually do not change, that's just part of being embedded, modules dont really make sense there unless things like filesystems and non-device modules never get used at the same time and memory is limited such that 100KB actually matters.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea.
True, but how about we start being good memory users where it counts the most, like gui's/userspace land and then worry about the sub 1MB usage that kernels exist in.
Quoted 6 lines
Quoted 2 lines
The biggest modules are about 100k. Saving 100k of 1 GB doesn't really seem worth any effort.
I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k is worth the effort.
Then why do you use a sylpheed, which is gtk instead of something in a terminal that uses much less memory (doesn't require xfree86, which you're probably also using instead of tinyX) and toolkits, pixmaps etc.
Obviously, 100k is not worth _your_ effort.
I'm not saying module use is more memory efficient than not or vice versa, but if memory usage in the 100K range is going to be the only argument for autoloading/unloading of modules then it's really _not_ worth the effort unless someone can give that kind of support without trying. Your fight for memory efficiency should start where the inefficiency is the largest, and work it's way down, not the other way around.
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 24 lines · Ed Sweetman
Quoted 14 lines · Witukind
Quoted 10 lines · On Wed, 10 Dec 2003 20:33:24 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 7 lines · Witukind
Quoted 4 lines · On Tue, 09 Dec 2003 10:39:32 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 2 lines
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
I believe the original motivation for module autoloading was to
save> memory by unloading modules when their devices were unused. Loading> them automatically on demand made for less trouble for users, who> didn't have to run modprobe manually to use the sound
card, or> whatever. This could still be a good thing in embedded
systems.>
Quoted 17 lines
the biggest advantage from modules is the ability to enable/disable devices with different initialization configurations without rebooting, including the use of devices that aren't present during boot or may be added to a system that cant be put down to reboot. Embedded systems usually do not change, that's just part of being embedded, modules dont really make sense there unless things like filesystems and non-device modules never get used at the same time and memory is limited such that 100KB actually matters.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea.
True, but how about we start being good memory users where it counts the most, like gui's/userspace land and then worry about the sub 1MB usage that kernels exist in.
Quoted 7 lines
Quoted 2 lines
The biggest modules are about 100k. Saving 100k of 1 GB doesn't really seem worth any effort.
I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k is worth the effort.
Blah, scratch this.
Quoted 2 lines
Then why do you use a sylpheed, which is gtk instead of something in a terminal that uses much less memory (doesn't require xfree86, which you're probably also using instead of tinyX) and toolkits, pixmaps etc.
Obviously, 100k is not worth _your_ effort.
And of course that's all assuming you're using your laptop to write and send email. Which you probably wouldn't be doing on a 16MB laptop...probably wouldn't be doing anything on a 16MB laptop. But anyway, the rest of what i was talking about is ok.
Quoted 3 lines
I'm not saying module use is more memory efficient than not or vice versa, but if memory usage in the 100K range is going to be the only argument for autoloading/unloading of modules then it's really _not_ worth the effort unless someone can give that kind of support without trying. Your fight for memory efficiency should start where the inefficiency is the largest, and work it's way down, not the other way around.
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 62 lines · On Wed, 10 Dec 2003 15:53:03 -0500 Ed Sweetman <[email protected]> wrote:
Quoted 44 lines · Ed Sweetman
Quoted 8 lines · Witukind
Quoted 4 lines · On Wed, 10 Dec 2003 20:33:24 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 1 line · Witukind
On Tue, 09 Dec 2003 10:39:32 +0100 [email protected] (Måns Rullgård)
wrote:>>>
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
I believe the original motivation for module autoloading was to
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
save> memory by unloading modules when their devices were unused.
Loading> them automatically on demand made for less trouble for users, who> didn't have to run modprobe manually to use the sound card, or> whatever. This could still be a good thing in embedded systems.>
the biggest advantage from modules is the ability to enable/disable devices with different initialization configurations without rebooting, including the use of devices that aren't present during boot or may be added to a system that cant be put down to reboot. Embedded systems usually do not change, that's just part of being embedded, modules dont really make sense there unless things like filesystems and non-device modules never get used at the same time and memory is limited such that 100KB actually matters.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea.
True, but how about we start being good memory users where it counts the most, like gui's/userspace land and then worry about the sub 1MB usage that kernels exist in.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
The biggest modules are about 100k. Saving 100k of 1 GB doesn't really seem worth any effort.
I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving
100k > is worth
Quoted 1 line
the effort.
Blah, scratch this.
Quoted 5 lines
Then why do you use a sylpheed, which is gtk instead of something in a terminal that uses much less memory (doesn't require xfree86, which you're probably also using instead of tinyX) and toolkits, pixmaps etc.
Obviously, 100k is not worth _your_ effort.
Quoted 4 lines
And of course that's all assuming you're using your laptop to write and send email. Which you probably wouldn't be doing on a 16MB laptop...probably wouldn't be doing anything on a 16MB laptop. But anyway, the rest of what i was talking about is ok.
Well you can do a lot of things on this laptop and Wingdows 95, although I'd prefer to be able to do as much or even more using Linux with it.
Signature · 1 line
Jabber: [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Ed SweetmanQuoted 54 lines · On Wed, 10 Dec 2003 15:47:01 -0500 Ed Sweetman <[email protected]> wrote:
Quoted 4 lines · Witukind
On Wed, 10 Dec 2003 20:33:24 +0100
[email protected] (Måns Rullgård) wrote:Quoted 17 lines
Quoted 4 lines
Quoted 1 line · Witukind
On Tue, 09 Dec 2003 10:39:32 +0100 [email protected] (Måns Rullgård)
wrote:>>
Quoted 12 lines
Quoted 12 lines
Quoted 5 lines
Quoted 3 lines
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
I believe the original motivation for module autoloading was to
save> memory by unloading modules when their devices were unused. Loading> them automatically on demand made for less trouble for users, who> didn't have to run modprobe manually to use the sound card, or> whatever. This could still be a good thing in embedded systems.>
the biggest advantage from modules is the ability to enable/disable devices with different initialization configurations without rebooting, including the use of devices that aren't present during boot or may be added to a system that cant be put down to reboot. Embedded systems usually do not change, that's just part of being embedded, modules dont really make sense there unless things like filesystems and non-device modules never get used at the same time and memory is limited such that 100KB actually matters.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea.
True, but how about we start being good memory users where it counts the most, like gui's/userspace land and then worry about the sub 1MB usage that kernels exist in.
Quoted 6 lines
Quoted 2 lines
The biggest modules are about 100k. Saving 100k of 1 GB doesn't really seem worth any effort.
I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k is worth the effort.
Then why do you use a sylpheed, which is gtk instead of something in a
terminal that uses much less memory (doesn't require xfree86, which you're probably also using instead of tinyX) and toolkits, pixmaps etc.
Obviously, 100k is not worth _your_ effort.
Quoted 11 lines
I'm not saying module use is more memory efficient than not or vice versa, but if memory usage in the 100K range is going to be the only argument for autoloading/unloading of modules then it's really _not_ worth the effort unless someone can give that kind of support without trying. Your fight for memory efficiency should start where the inefficiency is the largest, and work it's way down, not the other way
around.
Well first of all, how do you know I am using the laptop right now? I don't use X on it actually, not even tinyX (anyway the video card is not supported by XFree86). Secondly what if I don't like text mode or the available text mode email clients? The thing is I want to get the most out of my hardware, so every opportunity to decrease RAM usage, CPU cycles and increase the speed and responsiveness is good. I do agree with you that there is much bloat in Gtk (especially 2.x). The thing is also it's not just ONE module.
Signature · 1 line
Jabber: [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Witukind <[email protected]> writes:
[about memory used by modules]
Quoted 1 line
The thing is also it's not just ONE module.
The total size of all modules loaded on my laptop right now (31 in all) is 960k. Not much of a save compared to the total 640 MB.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 8 lines · On Wed, 10 Dec 2003 22:48:31 +0100 [email protected] (Måns Rullgård) wrote:
Witukind <[email protected]> writes:
[about memory used by modules]
Quoted 1 line
The thing is also it's not just ONE module.
The total size of all modules loaded on my laptop right now (31 in all) is 960k. Not much of a save compared to the total 640 MB.
It depends on which system. I have more than 31 (more like 50-60) useful modules even on the laptop. But anyway, in general any amount of saved RAM is good. It's a question of efficiency.
Signature · 1 line
Jabber: [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Ed SweetmanQuoted 8 lines · Ed Sweetman
the biggest advantage from modules is the ability to enable/disable devices with different initialization configurations without rebooting, including the use of devices that aren't present during boot or may be added to a system that cant be put down to reboot. Embedded systems usually do not change, that's just part of being embedded, modules dont really make sense there unless things like filesystems and non-device modules never get used at the same time and memory is limited such that 100KB actually matters.
An embedded system could still have USB or something like that. Many PDAs do have pluggable hardware modules.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Ed SweetmanQuoted 7 lines
I'm not saying module use is more memory efficient than not or vice versa, but if memory usage in the 100K range is going to be the only argument for autoloading/unloading of modules then it's really _not_ worth the effort unless someone can give that kind of support without trying. Your fight for memory efficiency should start where the inefficiency is the largest, and work it's way down, not the other way around.
That's not quite true - all kernel memory is statically mapped into ram and unswappable. 2 MB's of X will likely end up 80% swapped to disk and the rest is in use (and can still be swapped out when no longer needed). 100KB of an unused driver will not get swapped out.
That's where the difference is. As for using small userspace? I do, djbdns for dns, twm for window manager etc etc...
Cheers,
MaZe.
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 7 lines · Maciej Zenczykowski
Quoted 7 lines
I'm not saying module use is more memory efficient than not or vice versa, but if memory usage in the 100K range is going to be the only argument for autoloading/unloading of modules then it's really _not_ worth the effort unless someone can give that kind of support without trying. Your fight for memory efficiency should start where the inefficiency is the largest, and work it's way down, not the other way around.
Quoted 6 lines
That's not quite true - all kernel memory is statically mapped into ram and unswappable. 2 MB's of X will likely end up 80% swapped to disk and the rest is in use (and can still be swapped out when no longer needed). 100KB of an unused driver will not get swapped out.
That's where the difference is. As for using small userspace? I do, djbdns for dns, twm for window manager etc etc...
I was under the impression, that on the x86 processors, it is not possible to have more than ~640Kb of 'unswappable' memory. Everything else *is* swappable.
Perhaps somebody with understanding could enlighten us on this point?
Is kernel code swappable if compiled in statically? I have assumed that it is.
mark
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 3 lines · Mark Mielke
I was under the impression, that on the x86 processors, it is not possible to have more than ~640Kb of 'unswappable' memory. Everything else *is* swappable.
Swappable or not doesn't depend on physical memory address. It depends on whether the kernel memory management allows it or not. No Linux kernels to date will swap out kernel memory. The swappability of a page is determined by some flags when it is allocated.
Quoted 4 lines
Perhaps somebody with understanding could enlighten us on this point?
Is kernel code swappable if compiled in statically? I have assumed that it is.
That's not the way it works.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 8 lines · Måns Rullgård
Quoted 3 lines · Mark Mielke
I was under the impression, that on the x86 processors, it is not possible to have more than ~640Kb of 'unswappable' memory. Everything else *is* swappable.
Swappable or not doesn't depend on physical memory address. It depends on whether the kernel memory management allows it or not. No Linux kernels to date will swap out kernel memory. The swappability of a page is determined by some flags when it is allocated.
Is this something that should be fixed? Or is this a related issue where the perceived gain is small enough that it isn't worth tackling, or modules is the recommended and desirable solution to this problem?
Is Microsoft Windows different in this regard?
mark
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to WitukindQuoted 17 lines · Witukind
Quoted 14 lines · On Wed, 10 Dec 2003 20:33:24 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 12 lines · Witukind
Quoted 4 lines · On Tue, 09 Dec 2003 10:39:32 +0100 [email protected] (Måns Rullgård) wrote:
Quoted 2 lines
Is there a specific case for which people want this feature? Offhand it seems like a slightly odd thing to ask for...
I believe the original motivation for module autoloading was to
save> memory by unloading modules when their devices were unused. Loading> them automatically on demand made for less trouble for users, who> didn't have to run modprobe manually to use the sound card, or> whatever. This could still be a good thing in embedded systems.>
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea.
The biggest modules are about 100k. Saving 100k of 1 GB doesn't really seem worth any effort.
I don't have 1 Gb of memory. On my laptop with 16 mb RAM saving 100k is worth the effort.
In that case I don't classify your laptop as a regular system any more. I remember saying that the space saving could be worthwhile on small systems a while back.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Måns RullgårdQuoted 5 lines
Quoted 2 lines
I don't see why it wouldn't be a good thing for regular systems also. Saving memory is usually a good idea.
The biggest modules are about 100k. Saving 100k of 1 GB doesn't really seem worth any effort.
so let's cut kernel module support period and make the kernel fully monolithic. this will also solve the binary module vs gpl issue and everyone will be happy...
cheers,
maze.
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Greg KHQuoted 9 lines · Greg KH
Quoted 6 lines
That's something I don't understand: I thought that with a well configured hotplug+udev system, you'll never have to worry about loading drivers on device-node
open()because all drivers should be auto-loaded and all device-nodes should be auto-created.Am I wrong ?
No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either.
So to attenuate people's worries it should be stated in some form:
A: Such a functionality isn't needed on a properly configured
system. All devices present on the system should generate hotplug events, loading the appropriate driver, and udev should notice and create the appropriate device node. In case of failure, please make a proper bug report.
Of course, you'll have to translate it to correct english.
Xav
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Am I wrong ?
No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either.
You are of course totally wrong - just because a device is present in the system doesn't mean that it's kernel modules are loaded - for example my floppy is always present in the system, but I access it like once a month or so - currently devfs (which I'm using on 3 computers with no problems for over a year now) will load the floppy module on access to /dev/fd0 and the module will unload automatically a few dozen minutes later after I'm done with the disk drive. On an 8 MB mem system keeping 60KB floppy driver non-stop in unswappable kernel memory is wastefull. Especially since this also applies to microcode, sound drivers, scanners, rtc, etc... The system is properly configured - the modules for devices are loaded when needed - just because a device is present doesn't mean we need to have the driver loaded for it.
Quoted 5 lines
A: Such a functionality isn't needed on a properly configured
system. All devices present on the system should generate hotplug events, loading the appropriate driver, and udev should notice and create the appropriate device node. In case of failure, please make a proper bug report.
Cheers,
MaZe.
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 8 lines · Maciej Zenczykowski
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Am I wrong ?
No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either.
You are of course totally wrong - just because a device is present in the system doesn't mean that it's kernel modules are loaded - for example my floppy is always present in the system, but I access it like once a month or so - currently devfs (which I'm using on 3 computers with no problems for over a year now) will load the floppy module on access to
/dev/fd0and the module will unload automatically a few dozen minutes later after I'm done with the disk drive. On an 8 MB mem system keeping 60KB floppy driver non-stop in unswappable kernel memory is wastefull. Especially since this also applies to microcode, sound drivers, scanners, rtc, etc... The system is properly configured - the modules for devices are loaded when needed - just because a device is present doesn't mean we need to have the driver loaded for it.
Sure, the driver doesn't need to be present all the time. If you want to use it occationally you need some kind of "trigger" to demand-load it.
With devfs, this trigger mechanism is devfs+devfsd and its configuration. Devfs will notice that you're opening a nonexistant node, tell devfsd do do something, devfsd will see that you have specified module loading, do that, and then the suddenly present node is loaded.
The approach without devfs is to have the device node present wheter or not the device is there. (i.e. /dev on ext2)
You don't need a /dev full of all the nodes makedev creates, but you need nodes for devices you actually have. Set up udev so it don't delete nodes (or at least not the floppy node) when the driver go away. You now have a permanent floppy device. Trying to access it when it isn't there will cause the kernel itself to run modprobe, if you configured "automatic module loading".
So, you can demand-load devices without devfs, you just need the device node. It wastes little disk space and no memory (unless you put your udev-managed /dev in tmpfs. But then the memory loss is quite small and the disk loss nonexistant.)
You can probably have udev help you set up the device nodes, configure so nodes aren't deleted and load all your modules. udev populates /dev and that job is done.
Compare to the devfs approach:
It too uses memory (for devfs and devfsd, as well as disk space for devfsd.conf. And there is one disadvantage, a program cannot look in /dev to see what devices you have when the module isn't loaded. A program looking for floppy or sound devices won't find any with devfs+modules, but will find the device if you're using udev+modules. And then the driver will load when opened.
Helge Hafting
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Maciej ZenczykowskiQuoted 6 lines · Maciej Zenczykowski
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Am I wrong ?
No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either.
You are of course totally wrong
Oh, ok. I'll just go back to writing code instead of arguing...
Quoted 2 lines
- just because a device is present in the system doesn't mean that it's kernel modules are loaded
No, but one could argue that it should :)
Quoted 2 lines
- for example my floppy is always present in the system, but I access it like once a month or so
Then, when you want to access it, a simple 'modprobe floppy' would work for you, right?
Anyway, I'm not going to drag this thread out anymore. If you want to use devfs, do it. Just realize that it is an obsolete kernel feature and is marked for probable removal in 2.7. It also has known bad problems that could cause your machine to lock up. Use it at your own risk, you have been warned...
greg k-h
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 6 lines · Greg KH
Quoted 2 lines · Maciej Zenczykowski
- just because a device is present in the system doesn't mean that it's kernel modules are loaded
No, but one could argue that it should :)
One could equally well argue that it need not.
Quoted 5 lines
Quoted 2 lines
- for example my floppy is always present in the system, but I access it like once a month or so
Then, when you want to access it, a simple 'modprobe floppy' would work for you, right?
Only if you are root.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 7 lines · Måns Rullgård
Quoted 5 lines
Quoted 2 lines
- for example my floppy is always present in the system, but I access it like once a month or so
Then, when you want to access it, a simple 'modprobe floppy' would work for you, right?
Only if you are root.
Come on ... the stock kernel from your distribution will do the modprobe for you when you access the floppy, I'm sure you're skilled enough to configure your own kernel to do the same.
And if you don't want to recompile, just chmod +s modprobe - on your small machine which needs to save 60k, I bet you're the only user. Or use sudo.
Xav
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 9 lines · On Wed, 10 Dec 2003 08:02:46 +0100 Xavier Bestel <[email protected]> wrote:
Quoted 7 lines · Måns Rullgård
Quoted 5 lines
Quoted 1 line
- for example my floppy is always present in the system, but I
access> it like once a month or so
Then, when you want to access it, a simple 'modprobe floppy' would work for you, right?
Only if you are root.
Quoted 8 lines
Come on ... the stock kernel from your distribution will do the modprobe for you when you access the floppy, I'm sure you're skilled enough to configure your own kernel to do the same.
And if you don't want to recompile, just chmod +s modprobe - on your small machine which needs to save 60k, I bet you're the only user. Or use sudo.Xav
I was expecting this kind of reply. Like "if you have an older hardware you can fuck off".
Signature · 1 line
Jabber: [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 9 lines · Witukind
Quoted 7 lines · On Wed, 10 Dec 2003 08:02:46 +0100 Xavier Bestel <[email protected]> wrote:
Come on ... the stock kernel from your distribution will do the modprobe for you when you access the floppy, I'm sure you're skilled enough to configure your own kernel to do the same.
And if you don't want to recompile, just chmod +s modprobe - on your small machine which needs to save 60k, I bet you're the only user. Or use sudo.
Quoted 4 lines
Quoted 1 line
Xav
I was expecting this kind of reply. Like "if you have an older hardware you can fuck off".
Wow ... how can you understand this in my text ? Because I'm guessing he is the only user on his machine ? This has nothing to do with small machines, but with system configuration: load on-demand may be done without devfs.
Well, I wish do apologize to Måns if he thought I was ridiculing his hardware. Just take out the last sentence with "modprobe" if it bothers you.
Xav
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 12 lines · Xavier Bestel
Quoted 11 lines · Witukind
Quoted 8 lines · On Wed, 10 Dec 2003 08:02:46 +0100 Xavier Bestel <[email protected]> wrote:
Come on ... the stock kernel from your distribution will do the modprobe for you when you access the floppy, I'm sure you're skilled enough to configure your own kernel to do the same.
And if you don't want to recompile, just chmod +s modprobe - on your small machine which needs to save 60k, I bet you're the only user. Or use sudo.Xav
Quoted 7 lines
Quoted 2 lines
I was expecting this kind of reply. Like "if you have an older hardware you can fuck off".
Wow ... how can you understand this in my text ? Because I'm guessing he is the only user on his machine ? This has nothing to do with small machines, but with system configuration: load on-demand may be done without devfs.
It certainly can be done without devfs. I was objecting to the udev way of thinking that all drivers are always loaded. If you want to use udev and on-demand loading, you need to do some tweaking.
Quoted 3 lines
Well, I wish do apologize to Måns if he thought I was ridiculing his hardware. Just take out the last sentence with "modprobe" if it bothers you.
Well, my hardware is as good as any.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 3 lines · Måns Rullgård
I was objecting to the udev
way of thinking that all drivers are always loaded. If you want to use udev and on-demand loading, you need to do some tweaking.
Technically it's hotplug which assumes that all drivers are always to be loaded. But you are right.
And even there, I'd say hotplug+udev has the advantage: being userland scripts, they can be tweaked to meet your needs (like on-demand loading only your floppy, in your case). Unlike devfs.
Mechanism, not policy, etc.
Xav
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Xavier BestelQuoted 11 lines · Xavier Bestel
Quoted 9 lines · Greg KH
Quoted 6 lines
That's something I don't understand: I thought that with a well configured hotplug+udev system, you'll never have to worry about loading drivers on device-node
open()because all drivers should be auto-loaded and all device-nodes should be auto-created.Am I wrong ?
No, you are correct. That's why I'm not really worried about this, and I don't think anyone else should be either.
Quoted 7 lines
So to attenuate people's worries it should be stated in some form:
A: Such a functionality isn't needed on a properly configured
system. All devices present on the system should generate hotplug events, loading the appropriate driver, and udev should notice and create the appropriate device node. In case of failure, please make a proper bug report.
Thanks, I've now updated the udev FAQ with much this kind of wording to hoefully prevent this kind of thread happening again (hey, I can dream, can't I?) It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
greg k-h
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Xavier BestelQuoted 10 lines · Xavier Bestel
Quoted 3 lines
A: That is correct. If you really require this functionality, then
use devfs. There is no way that udev can support this, and it never will.That's something I don't understand: I thought that with a well configured hotplug+udev system, you'll never have to worry about loading drivers on device-node
open()because all drivers should be auto-loaded and all device-nodes should be auto-created.Am I wrong ?
Let me give an example. Hotplug will automatically load the ALSA drivers for my sound card, and /dev/snd/* are created (by devfs or udev, it doesn't matter for now). Suppose that, some time, I run a program that tries to use OSS for sound. Now, the ALSA OSS emulation is not loaded by hotplug, and I don't want it to. It's nice to have snd-pcm-oss automatically loaded when some legacy application tries to use /dev/dsp.
Signature · 2 lines
Måns Rullgård [email protected]
Re: udev sysfs docs Re: State of devfs in 2.6?
Quoted 7 lines · [email protected] (Måns Rullgård) writes:
Let me give an example. Hotplug will automatically load the ALSA drivers for my sound card, and
/dev/snd/*are created (by devfs or udev, it doesn't matter for now). Suppose that, some time, I run a program that tries to use OSS for sound. Now, the ALSA OSS emulation is not loaded by hotplug, and I don't want it to. It's nice to have snd-pcm-oss automatically loaded when some legacy application tries to use/dev/dsp.
For this sort of case it seems like it would be much cleaner to have some sort of proxy device that would load the module upon open -- so the also drivers would end up creating both alsa entries in /dev, and also proxy entries for the supported oss devices.
That way, you could have the explicit device entry (which I think is all around saner), but not the overhead of rarely used modules.
-Miles
Signature · 4 lines
In New York, most people don't have cars, so if you want to kill a person, you have to take the subway to their house. And sometimes on the way, the train is delayed and you get impatient, so you have to kill someone on the subway. [George Carlin]
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Greg KHQuoted 10 lines · Greg KH
Quoted 8 lines · Witukind
From the udev FAQ:
Q: But udev will not automatically load a driver if a /dev node is opened
when it is not present like devfs will do.
A: If you really require this functionality, then use devfs. It is still
present in the kernel.Will it have this 'equivalent functionality' some day?
Quoted 7 lines
Heh, no. I really don't believe all of the people who keep asking me this. I think I need to reword this answer to something like:
A: That is correct. If you really require this functionality, then
use devfs. There is no way that udev can support this, and it never will.That better? :)
No Greg. People keep asking, because you continue to give an answer that is 'correct' but does not answer the question people 'meant' to ask.
Andreas Jellinghaus <[email protected]> gave an excellent answer - which I shall blatantly quote:
-------------------------
Q: devfs did load drivers when someone tried to open() a non existing device. will sysfs/hotplug/udev do this?
A: there is no need to. hotplug/sysfs/udev will create devices for all hardware supported by the kernel and the available modules. it will do that during boot up, and whenever new hardware is added. so you can expect all devices be already present, no need for a devfs like mechanism.
-------------------------
And there you have it :)
/ jakob
Re: udev sysfs docs Re: State of devfs in 2.6?
In reply to Greg KHQuoted 16 lines · Greg KH
Quoted 8 lines · Witukind
From the udev FAQ:
Q: But udev will not automatically load a driver if a /dev node is opened
when it is not present like devfs will do.
A: If you really require this functionality, then use devfs. It is still
present in the kernel.Will it have this 'equivalent functionality' some day?
Heh, no. I really don't believe all of the people who keep asking me this. I think I need to reword this answer to something like:
A: That is correct. If you really require this functionality, then
use devfs. There is no way that udev can support this, and it never will.
Quoted 5 lines
That better? :)
thanks,
greg k-h
I think another way of saying it is that we now have a hotplug infrastructure to load the driver on an insert event, so if you want to load the driver for something that A) isn't detected on startup, B) isn't detected on a hotplug event when it's inserted after startup, the way to do it is to call modprobe, not to mknod a random device node and then try to open it and hope some magic side effect of open loads the correct module with the right parameters to make things work.
The driver is now loaded while the device is attached to the system, not just while the device is in use. (Less races that way, you get to save state between invocations, etc.) The lifetime rules changed.
The old way of doing it assumes you have a device node for a device that has no driver loaded, which was the default under the old static /dev but not the case in a fully hotplug system. You have /dev nodes for devices that are in the system (with drivers loaded), and you don't for ones that aren't.
Rob
(I could be completely wrong about all this, of course...)
Quoted 3 lines · William Lee Irwin III
I would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism.
huh?
aj@simulacron:/dev$ find -type c -mount |grep -v pty |wc -l
164
aj@simulacron:/dev$ find -type b |wc -l
157
aj@simulacron:/dev$ find /sys/ -name dev |wc -l
250After ignoring .devfsd we are left with 70 devices missing:
- 15 floppy devices
- 5 input/ devices
- full, kmem, kmsg, mem, null, port, random, urandom, zero
- printers/0
- 5 misc/ devices
- 12 snd/ devices
- 5 sound/ devices
- 18 vcc/ devices
I wouldn't call udev deprecated, unless a newer kernel has the essential devices, too. And is there a udev version that can do devfs names? last time I checked only lanana names were supported.
Some distributions were quite happy to move from /dev and lanana to devfs with better names. I doubt everyone will rush to udev with lanana names, and re-introducing makedev for devices not represented in sysfs doesn't sound very nice either. So 2.8.* might be a nice time frame for dropping devfs, or at least give sysfs and udev a few months to catch up on the issues mentioned.
Andreas
Quoted 14 lines · Andreas Jellinghaus
Quoted 3 lines · William Lee Irwin III
I would say it's deprecated at the very least. sysfs and udev are supposed to provide equivalent functionality, albeit by a somewhat different mechanism.
huh?
aj@simulacron:/dev$ find -type c -mount |grep -v pty |wc -l 164 aj@simulacron:/dev$ find -type b |wc -l 157 aj@simulacron:/dev$ find /sys/ -name dev |wc -l 250
Quoted 2 lines
After ignoring .devfsd we are left with 70 devices missing:
- 15 floppy devices
You have 15 floppy devices connected to your box? All floppy devices should show up in /sys/block.
Quoted 1 line
- 5 input/ devices
Patch for sysfs support for this has been posted by Hanna Linder. It still needs work before being added to the kernel tree.
Quoted 1 line
- full, kmem, kmsg, mem, null, port, random, urandom, zero
Patch for this has been posted by me to lkml in the past. It will probably go into 2.6.1
Quoted 1 line
- printers/0
Hanna Linder is working on a patch for these devices.
Quoted 1 line
- 5 misc/ devices
Patch for this has been posted by me to lkml in the past. It will probably go into 2.6.1.
Quoted 2 lines
- 12 snd/ devices
- 5sound/devices
I have a patch here from Leann Ogasawara that adds sysfs support for these devices. I've been lacking time to test it better, but again, it will probably make it into 2.6.1.
Quoted 1 line
- 18 vcc/ devices
Hm, good catch. I wonder why these aren't getting picked up in /sys/class/tty as they are tty devices. I thought they used to be there...
Quoted 2 lines
I wouldn't call udev deprecated, unless a newer kernel has the essential devices, too.
You mean s/udev/devfs/ right? :)
Quoted 2 lines
And is there a udev version that can
do devfs names? last time I checked only lanana names were supported.
There is a udev config file that was just posted to linux-hotplug-devel that supports a lot of devfs names. If there are any missing that you use, please post a config file for them.
Remember, I don't use devfs, so I really don't care about a udev mapping for it :)
Quoted 2 lines
Some distributions were quite happy to move from /dev and lanana to devfs with better names.
Hm, 2? And one of them (Mandrake) got smart and went back...
Quoted 1 line
I doubt everyone will rush to udev with lanana names,
Why not? It's the standard afterall. Remember, the devfs users are in the tiny minority here.
Quoted 5 lines
and
re-introducing makedev for devices not represented
in sysfs doesn't sound very nice either. So 2.8.* might be a nice time frame for dropping devfs, or at least give sysfs and udev a few months to catch up on the issues mentioned.
Regardless of the state of udev, devfs has insolvable problems and you should not use it. End of story.
thanks,
greg k-h
Quoted 5 lines · Greg KH
Quoted 2 lines
After ignoring .devfsd we are left with 70 devices missing:
- 15 floppy devicesYou have 15 floppy devices connected to your box? All floppy devices should show up in
/sys/block.
perhaps he means fd0u1440, fd0u1600 and friends
ls /dev/fd0u*|wc -l -> 15
c'ya
sven
Signature · 2 lines
The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/)
Quoted 11 lines · Sven-Haegar Koch
Quoted 5 lines · Greg KH
Quoted 2 lines
After ignoring .devfsd we are left with 70 devices missing:
- 15 floppy devicesYou have 15 floppy devices connected to your box? All floppy devices should show up in
/sys/block.perhaps he means fd0u1440, fd0u1600 and friends
ls /dev/fd0u*|wc -l -> 15
Yeah, but are those devices actually connected all at once? Yeah, I know the way of talking to the same device in different manners...
Hm, udev can now do symlinks, does it also need to handle multiple minors for floppy devices? I'll have to look into how the kernel handles the different block minors for floppy devices.
thanks,
greg k-h
PATCH 1/1 sysfs support for vcs devices (was Re: State of devfs in 2.6?)
In reply to Greg KHQuoted 6 lines · Greg KH
Quoted 1 line · Andreas Jellinghaus
- 18 vcc/ devices
Hm, good catch. I wonder why these aren't getting picked up in
/sys/class/ttyas they are tty devices. I thought they used to be there...
Ah, they really aren't tty devices, they are char devices. That's why they never have showed up.
Anyway, here's a patch against 2.6.0-test11 that adds sysfs support for all of the vcs devices. Now udev has support for them :)
thanks for pointing these out,
greg k-h
# add /sys/class/vc support for the vcs devices.
drivers/char/vc_screen.c +87 -0
@@ -36,6 +36,7 @@#include <linux/kbd_kern.h> #include <linux/console.h> #include <linux/smp_lock.h> +#include <linux/device.h> #include <asm/uaccess.h> #include <asm/byteorder.h> #include <asm/unaligned.h>
@@ -469,6 +470,85 @@ .open = vcs_open, }; +/* vc class implementation */ + +struct vc_dev { +struct list_head node; +dev_t dev; +struct class_device class_dev; +}; +#define to_vc_dev (d) container_of(d, struct vc_dev, class_dev) + +static LIST_HEAD (vc_dev_list); +static spinlock_t vc_dev_list_lock =SPIN_LOCK_UNLOCKED ; + +static void release_vc_dev (struct class_device *class_dev) +{ +struct vc_dev *vc_dev =to_vc_dev (class_dev); +kfree (vc_dev); +} + +static struct class vc_class = { + .name ="vc" , + .release = &release_vc_dev, +}; + +static ssize_t show_dev (struct class_device *class_dev,char *buf) +{ +struct vc_dev *vc_dev =to_vc_dev (class_dev); +return print_dev_t (buf, vc_dev->dev); +} +static CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL); + +static int vc_add_class_device (dev_t dev,char *name,int minor) +{ +struct vc_dev *vc_dev =NULL ; +int retval; + + vc_dev =kmalloc (sizeof (*vc_dev),GFP_KERNEL ); +if (!vc_dev) +return -ENOMEM ; +memset (vc_dev,0x00 ,sizeof (*vc_dev)); + + vc_dev->dev = dev; + vc_dev->class_dev.class = &vc_class; +snprintf (vc_dev->class_dev.class_id,BUS_ID_SIZE , name, minor); + retval =class_device_register (&vc_dev->class_dev); +if (retval) + goto error; +class_device_create_file (&vc_dev->class_dev, &class_device_attr_dev); +spin_lock (&vc_dev_list_lock); +list_add (&vc_dev->node, &vc_dev_list); +spin_unlock (&vc_dev_list_lock); +return 0 ; +error: +kfree (vc_dev); +return retval; +} + +static void vc_remove_class_device (int minor) +{ +struct vc_dev *vc_dev =NULL ; +struct list_head *tmp; +int found =0 ; + +spin_lock (&vc_dev_list_lock); +list_for_each (tmp, &vc_dev_list) { + vc_dev = list_entry(tmp, struct vc_dev, node); +if (MINOR (vc_dev->dev) == minor) { + found =1 ; +break ; + } + } +if (found) { +list_del (&vc_dev->node); +spin_unlock (&vc_dev_list_lock); +class_device_unregister (&vc_dev->class_dev); + }else { +spin_unlock (&vc_dev_list_lock); + } +} +void vcs_make_devfs (struct tty_struct *tty) { devfs_mk_cdev(MKDEV(VCS_MAJOR, tty->index + 1),
@@ -477,19 +557,26 @@devfs_mk_cdev (MKDEV (VCS_MAJOR , tty->index +129 ),S_IFCHR |S_IRUSR |S_IWUSR ,"vcc/a%u" , tty->index +1 ); +vc_add_class_device (MKDEV (VCS_MAJOR , tty->index +1 ),"vcs%u" , tty->index +1 ); +vc_add_class_device (MKDEV (VCS_MAJOR , tty->index +129 ),"vcsa%u" , tty->index +1 ); }void vcs_remove_devfs (struct tty_struct *tty) {devfs_remove ("vcc/%u" , tty->index +1 );devfs_remove ("vcc/a%u" , tty->index +1 ); +vc_remove_class_device (tty->index +1 ); +vc_remove_class_device (tty->index +129 ); }int __init vcs_init (void ) {if (register_chrdev (VCS_MAJOR ,"vcs" , &vcs_fops))panic ("unable to get major %d for vcs device" ,VCS_MAJOR ); +class_register (&vc_class);devfs_mk_cdev (MKDEV (VCS_MAJOR ,0 ),S_IFCHR |S_IRUSR |S_IWUSR ,"vcc/0" );devfs_mk_cdev (MKDEV (VCS_MAJOR ,128 ),S_IFCHR |S_IRUSR |S_IWUSR ,"vcc/a0" ); +vc_add_class_device (MKDEV (VCS_MAJOR ,0 ),"vcs" ,0 ); +vc_add_class_device (MKDEV (VCS_MAJOR ,128 ),"vcsa" ,128 );return 0 ; }
Quoted 2 lines · Greg KH
You have 15 floppy devices connected to your box? All floppy devices should show up in
/sys/block.
No, 16 devices are normal, sysfs has only one:
aj@simulacron:~/torrent/j-tv/download$ ls /dev/floppy/ 0 0u1120 0u1600 0u1722 0u1760 0u1920 0u720 0u820 0u1040 0u1440 0u1680 0u1743 0u1840 0u360 0u800 0u830 aj@simulacron:~/torrent/j-tv/download$ find /sys/block/fd* -name dev /sys/block/fd0/dev
Are those floppy devices obsolete? fdformat was the only app to use them anyway, I guess. (Not that I use my floppy, I simply noticed the change.)
Quoted 4 lines
Quoted 2 lines
I wouldn't call udev deprecated, unless a newer kernel has the essential devices, too.
You mean s/udev/devfs/ right? :)
oops, sorry.
Quoted 8 lines
Quoted 5 lines
and
re-introducing makedev for devices not represented
in sysfs doesn't sound very nice either. So 2.8.* might be a nice time frame for dropping devfs, or at least give sysfs and udev a few months to catch up on the issues mentioned.Regardless of the state of udev, devfs has insolvable problems and you should not use it. End of story.
how many bug reports did you see in the last three months of people having problems with devfs? I don't doubt the problems in theory, but but I simply haven't seen them happening. Most users seem quite happy.
Andreas
Quoted 28 lines · Andreas Jellinghaus
Quoted 2 lines · Greg KH
You have 15 floppy devices connected to your box? All floppy devices should show up in
/sys/block.No, 16 devices are normal, sysfs has only one:
aj@simulacron:~/torrent/j-tv/download$ ls /dev/floppy/ 0 0u1120 0u1600 0u1722 0u1760 0u1920 0u720 0u820 0u1040 0u1440 0u1680 0u1743 0u1840 0u360 0u800 0u830 aj@simulacron:~/torrent/j-tv/download$ find /sys/block/fd* -name dev /sys/block/fd0/devAre those floppy devices obsolete? fdformat was the only app to use them anyway, I guess. (Not that I use my floppy, I simply noticed the change.)
Quoted 4 lines
Quoted 2 lines
I wouldn't call udev deprecated, unless a newer kernel has the essential devices, too.
You mean s/udev/devfs/ right? :)
oops, sorry.
Quoted 6 lines
Quoted 5 lines
and
re-introducing makedev for devices not represented
in sysfs doesn't sound very nice either. So 2.8.* might be a nice time frame for dropping devfs, or at least give sysfs and udev a few months to catch up on the issues mentioned.
Quoted 7 lines
Quoted 2 lines
Regardless of the state of udev, devfs has insolvable problems and you should not use it. End of story.
how many bug reports did you see in the last three months of people having problems with devfs? I don't doubt the problems in theory, but but I simply haven't seen them happening. Most users seem quite happy.
Actually, I think most users who have problems just disable devfs. Most of the people I know have done that. No point in making bug reports about something that is unmaintained and deprecated.
Signature · 1 line
Murray J. Root
Quoted 8 lines
Quoted 4 lines
how many bug reports did you see in the last three months of people having problems with devfs? I don't doubt the problems in theory, but but I simply haven't seen them happening. Most users seem quite happy.
Actually, I think most users who have problems just disable devfs. Most of the people I know have done that. No point in making bug reports about something that is unmaintained and deprecated.
No, not really.
Devfs for embedded devices is just great. It's all in the kernel, no external process to run (I use my embedded stuff without devfsd). I'm using it for about one year with various kernels.
For me, I see several benefits:
* space. devfs doesn't eat space like the MAKEDEV approach.
* simplicity: I run my system without devfsd and without an initial ramdisk. All needed modules are simply compiled into the kernel.
* No need for overcomplification, e.g a process that has to be started before userspace touches /dev, a specially compiled uclibc-based proggy in an initrd
So, when /dev is accessed by userspace, all is there and well.
Signature · 2 lines
Try Linux 2.6 from BitKeeper for PXA2x0 CPUs at http://www.mn-logistik.de/unsupported/linux-2.6/
Quoted 3 lines · Holger Schurig
Devfs for embedded devices is just great.
* space. devfs doesn't eat space like the MAKEDEV approach.
Um, devfs does actually use a non-zero amount of code...
For a typical embedded device with about 5 entries in /dev I wouldn't be surprised if devfs used a lot _more_ space...
-miles
Signature · 3 lines
`...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist]
Quoted 3 lines
Quoted 1 line
* space. devfs doesn't eat space like the MAKEDEV approach.
Um, devfs does actually use a non-zero amount of code...
Yeh, it uses code. But if you look into a MAKEDEV bases file system, you see hundreds of device files. Which uses inode and directory space on the medium, may it be e2fs or jffs2.
I did not measure if the code for devfs is smaller as the code+config files for udev. But I didn't make a statement about this.
Quoted 2 lines
For a typical embedded device with about 5 entries in /dev I wouldn't be surprised if devfs used a lot _more_ space...
# find /dev | wc -l
326"Embedded" is not automatically a washing maschine with only 5 entries, it can be a full blown Linux computer with 400 MHz, Framebuffer, USB Host, USB Client, 7 serial ports for GSM, Barcode Scanner, Whatever, and so on. Like our device.
However, even on such hardware-rich devices you usually have a constraint on Flash Memory size. So having things small & simple is nice. That makes room for the user applications & data.
Signature · 2 lines
Try Linux 2.6 from BitKeeper for PXA2x0 CPUs at http://www.mn-logistik.de/unsupported/linux-2.6/
Quoted 3 lines · Holger Schurig
Devfs for embedded devices is just great. It's all in the kernel, no external process to run (I use my embedded stuff without devfsd). I'm using it for about one year with various kernels.
I don't see why 'all in the kernel' is the best approach, embedded or otherwise. I believe udev is being written to execute with a minimal runtime environment. No glibc, or other such beasts.
Quoted 1 line
* space. devfs doesn't eat space like the MAKEDEV approach.
Can you prove this? tmpfs doesn't seem to take up much space, and given that only devices that exist will require data structures in both cases, it seems to me that the issue is a little irrelevant in either case.
Quoted 2 lines
* simplicity: I run my system without devfsd and without an initial ramdisk. All needed modules are simply compiled into the kernel.
Isn't this an argument for udev?
Quoted 3 lines
* No need for overcomplification, e.g a process that has to be started before userspace touches /dev, a specially compiled uclibc-based proggy in an initrd
Many of us believe that devfs is 'over-complification'.
Quoted 1 line
So, when /dev is accessed by userspace, all is there and well.
True in either case...
mark
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Quoted 8 lines · Mark Mielke
Quoted 3 lines · Holger Schurig
Devfs for embedded devices is just great. It's all in the kernel, no external process to run (I use my embedded stuff without devfsd). I'm using it for about one year with various kernels.
I don't see why 'all in the kernel' is the best approach, embedded or otherwise. I believe udev is being written to execute with a minimal runtime environment. No glibc, or other such beasts.
Exactly. The current bk tree version of udev (which has more features than the 008 release) is weighing in at 49Kb, linked statically, no external dependancies.
greg k-h
Quoted 6 lines · Greg KH
Quoted 5 lines · Mark Mielke
Quoted 3 lines · Holger Schurig
Devfs for embedded devices is just great. It's all in the kernel, no external process to run (I use my embedded stuff without devfsd). I'm using it for about one year with various kernels.
Quoted 7 lines
Quoted 3 lines
I don't see why 'all in the kernel' is the best approach, embedded or otherwise. I believe udev is being written to execute with a minimal runtime environment. No glibc, or other such beasts.
Exactly. The current bk tree version of udev (which has more features than the 008 release) is weighing in at 49Kb, linked statically, no external dependancies.
And if we are talking about the smaller embedded systems it would be good to remember that their /dev doesn't really change much so devfs and udev could be left out entirely by having a small staticly populated /dev in the initramfs/initrd image, or whatever is used for /.
Signature · 5 lines
________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [email protected] Remember Cernan and Schmitt
[2.4.23] cursor dissapears in framebuffer console after switching back from X
In reply to Greg KHThis is 100% reproduceable on my machine. When I boot Linux the cursor can be seen. then I start XFree86 and when I switch back to the framebuffer console with ALT-CTRL-F(x) it is not there anymore. I am using tdfx.o with a Voodoo 3 2000 PCI, XFree86 4.3.0 (Slackware 9.1). If more information is needed I'll be glad to provide it.
Signature · 1 line
Jabber: [email protected]
Re: [2.4.23] cursor dissapears in framebuffer console after switching back from X
Quoted 6 lines · Witukind
This is 100% reproduceable on my machine. When I boot Linux the cursor can be seen. then I start XFree86 and when I switch back to the framebuffer console with ALT-CTRL-F(x) it is not there anymore. I am using tdfx.o with a Voodoo 3 2000 PCI, XFree86 4.3.0 (Slackware 9.1). If more information is needed I'll be glad to provide it.
This was asked by me a week or 2 back,and the answer is that in your .config that built your kernel, you probably have both a framebuffer for your card enabled, and a generic vesa framebuffer. Turn off the generic framebuffer and make/reinstall your kernel.
Signature · 7 lines
Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: [2.4.23] cursor dissapears in framebuffer console after switching back from X
Quoted 8 lines · On Thu, 11 Dec 2003 18:59:55 -0500 Gene Heskett <[email protected]>…
Quoted 6 lines · Witukind
This is 100% reproduceable on my machine. When I boot Linux the cursor can be seen. then I start XFree86 and when I switch back to the framebuffer console with ALT-CTRL-F(x) it is not there anymore. I am using tdfx.o with a Voodoo 3 2000 PCI, XFree86 4.3.0 (Slackware 9.1). If more information is needed I'll be glad to provide it.
Quoted 4 lines
This was asked by me a week or 2 back,and the answer is that in your .config that built your kernel, you probably have both a framebuffer for your card enabled, and a generic vesa framebuffer. Turn off the generic framebuffer and make/reinstall your kernel.
I don't have a VESA framebuffer enabled. Only tdfx.o.
Quoted 10 lines
Signature · 7 lines
Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.22% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Signature · 1 line
Jabber: [email protected]
Quoted 11 lines · Andreas Jellinghaus
Quoted 2 lines · Greg KH
You have 15 floppy devices connected to your box? All floppy devices should show up in
/sys/block.No, 16 devices are normal, sysfs has only one:
aj@simulacron:~/torrent/j-tv/download$ ls /dev/floppy/ 0 0u1120 0u1600 0u1722 0u1760 0u1920 0u720 0u820 0u1040 0u1440 0u1680 0u1743 0u1840 0u360 0u800 0u830 aj@simulacron:~/torrent/j-tv/download$ find /sys/block/fd* -name dev /sys/block/fd0/dev
Quoted 3 lines
Are those floppy devices obsolete? fdformat was the only app to use them anyway, I guess. (Not that I use my floppy, I simply noticed the change.)
I don't know if they are obsolete or not. I've never used them, and trying to figure out the floppy driver just makes my head hurt. I'm sure that if anyone really does use them, and udev doesn't work for them, I'll hear about it :)
Quoted 5 lines
Quoted 2 lines
Regardless of the state of udev, devfs has insolvable problems and you should not use it. End of story.
how many bug reports did you see in the last three months of people having problems with devfs?
I don't think that all 4 users of devfs on 2.6 are all that vocal :) Either way, I haven't been paying attention, as I really don't care.
Quoted 2 lines
I don't doubt the problems in theory, but but I simply haven't seen them happening. Most users seem quite happy.
There's no accounting for taste, is there. Anyway, sure some users might be happy, but when the kernel vfs maintainer shows that it's pretty simple to deadlock your kernel, and when the devfs maintainer disappears from view for over a year, that might be a good indication that you might want to stop using it.
Besides, there's only one "major" distro still using devfs, and that's just because they don't know any better.
thanks,
greg k-h
/me prepares for another onslaught of complaints from Gentoo users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greg KH wrote:
| On Tue, Dec 09, 2003 at 08:02:19AM +0100, Andreas Jellinghaus wrote: | |>>Regardless of the state of udev, devfs has insolvable problems and you |>>should not use it. End of story. |> |>how many bug reports did you see in the last three months of people |>having problems with devfs? | | | I don't think that all 4 users of devfs on 2.6 are all that vocal :) | Either way, I haven't been paying attention, as I really don't care. |
FWIW, I've been using devfs from the beginning of 2.4 and with 2.5/2.6 with Debian and never had a problem (knock on wood). I really like the way of having device nodes only for present devices.
Btw. I still haven't figured out, how to use udev properly. I just get the nodes of devices I plugin after boot and of the modules I load after boot. IDE et all aren't showing up. How early do I need to load udev or has my kernel to be all modular for it to work properly?
Thanks,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQE/1ZztLqMJRclVKIYRAlgWAJ0cFbRv2QbWrQbFNWACwHrp/opQiQCfZJVD UjI7PkOYwt4auQb1qTRtwx8=
=40wq
-----END PGP SIGNATURE-----
Quoted 5 lines · Jan Dittmer
Btw. I still haven't figured out, how to use udev properly. I just get the nodes of devices I plugin after boot and of the modules I load after boot. IDE et all aren't showing up. How early do I need to load udev or has my kernel to be all modular for it to work properly?
Since, I believe, version 006, udev has shipped with an init script contributed by rml that will create device nodes for devices present at system boot. You should be able to just make sure that that runs during your boot sequence and be fine. (I just ran this script on my system, and made sure it proper nodes for all my IDE drives and the partitions contained thereon.)
Matt
Quoted 4 lines · Jan Dittmer
Btw. I still haven't figured out, how to use udev properly. I just get the nodes of devices I plugin after boot and of the modules I load after boot. IDE et all aren't showing up. How early do I need to load udev or has my kernel to be all modular for it to work properly?
Like Matthew stated, either use the udev rc startup script, or put udev into your initramfs image to catch all of the early boot messages. Doing the initramfs method is still very tough to do right now, but people have reported success that way. I still recommend just using the init.d script for now.
Oh, and if you do have any udev problems, please post them to the linux-hotplug-devel mailing list.
thanks,
greg k-h
#include <hallo.h>
Quoted 5 lines · Greg KH
Like Matthew stated, either use the udev rc startup script, or put udev into your initramfs image to catch all of the early boot messages. Doing the initramfs method is still very tough to do right now, but people have reported success that way. I still recommend just using the init.d script for now.
Wouln't it be less error-prone to introduce a kind of queing for the hotplug program so kernel puts all the registered devices in a list and the list is submitted in one pass when udev asks for it?
MfG,
Eduard.
Quoted 9 lines · Eduard Bloch
#include <
hallo.h>Quoted 5 lines · Greg KH
Like Matthew stated, either use the udev rc startup script, or put udev into your initramfs image to catch all of the early boot messages. Doing the initramfs method is still very tough to do right now, but people have reported success that way. I still recommend just using the init.d script for now.
Quoted 3 lines
Wouln't it be less error-prone to introduce a kind of queing for the hotplug program so kernel puts all the registered devices in a list and the list is submitted in one pass when udev asks for it?
Heh, no. It's much easier to just run out of early userspace.
But that's just my opinion, if you think differently, I'd be very glad to see the code for your solution. :)
thanks,
greg k-h
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greg KH wrote:
| | I don't think that all 4 users of devfs on 2.6 are all that vocal :) | Either way, I haven't been paying attention, as I really don't care.
well ... I think there are more devfs users out there. eg, all the Gentoo freaks (me included) are sort of forced into devfs. If they want or not. And they will stick to it, until sysfs/udev/hotplug/foobarfs is so solid it can replace devfs.
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
Tequila Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/1oHQjBz/yQjBxz8RAuumAJ9y5mXjaMSSOA0D3HL9g0pz0wSYkACfW0NC OqFAQbBoSAdGJwciCJuPsck=
=MIoV
-----END PGP SIGNATURE-----
Skip to Bottom line: Does devfs do devpts on 2.6? Didn't for me.
Quoted 5 lines · Clemens Schwaighofer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Greg KH wrote:
Quoted 8 lines
| | I don't think that all 4 users of devfs on 2.6 are all that vocal :) | Either way, I haven't been paying attention, as I really don't care.well ... I think there are more devfs users out there. eg, all the Gentoo freaks (me included) are sort of forced into devfs. If they want or not. And they will stick to it, until sysfs/udev/hotplug/foobarfs is so solid it can replace devfs.
I'm using devfs on 2.6.0-test11. I have never run into the impossible to fix problems. I run devfs with very little old compatible naming. I edited /etc/devfs/compat_symlinks to give me /dev/sd* /dev/hd* and weirdly ln -s /dev/dsp2 /dev/dsp since all sound apps only seem to look for /dev/dsp which is only a dummy with nforce2.
In 2.6 devfs would not do devpts for X so I put devpts back in the kernel and instantly got on with my work. I'm not sure if that means devfs can't do devpts in 2.6. I don't care.
I see no devfs devices for a 32-bit cardbus pcmcia controller pci card which is id'd by yenta and cardmgr(pcmcia-cs v3.2.5), so I am switching to sysfs udev hotplug to see if that helps. Actually I can mount sysfs to /sys now and look around first but proc and var agree there is nada but there are two cards in slots.
In the cdrecord thread Linus said some things about target/bus/lun naming and I must admit that it is nice to get back where ls /dev shows what drives there are without having to tree out into /dev/scsi/host/bus/target/lun/* to see how drives are recognized. That can be improved in most configurations by using compat symlinks instructions for /dev/sd* in /etc/devfs/compat_symlinks but as Linus explained iscsi handled better by sysfs udev /dev/s?? and not 0,0,0 targbuslun cdrecord-style.
I like devfs and haven't ever had an error burning cd's with ide-scsi but I'm switching to udev and ide-cd to suck up to Linus before I start plaguing him about my pcmcia controller and yenta not working together--udev might work better with hotplug than devfs so I should try that first.
It seems dubious that Gooch isn't maintaining devfs and syfs could be moving away from compatibility with devfs, and there are proven impossibilities about the devfs way. Devfs is a lot less broken than windows, though. Devfs might be good enough to Walmart-Microsoft pretty good alright rip the guts out of userland, but that's not good enough for the os that runs the internet.
-Bob
Quoted 4 lines · Greg KH
Quoted 1 line
- 5 input/ devices
Patch for sysfs support for this has been posted by Hanna Linder. It still needs work before being added to the kernel tree.
I missed it. Where can I find it?
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Greg,
what about adding those patches to the hotplug utils directory, so people can find them easily and test sysfs+udev on empty /dev directories?
Regards, Andreas
Quoted 19 lines · Greg KH
Quoted 1 line
- 5 input/ devices
Patch for sysfs support for this has been posted by Hanna Linder. It still needs work before being added to the kernel tree.
Quoted 1 line
- full, kmem, kmsg, mem, null, port, random, urandom, zero
Patch for this has been posted by me to lkml in the past. It will probably go into 2.6.1
Quoted 1 line
- printers/0
Hanna Linder is working on a patch for these devices.
Quoted 1 line
- 5 misc/ devices
Patch for this has been posted by me to lkml in the past. It will probably go into 2.6.1.
Quoted 6 lines
Quoted 2 lines
- 12 snd/ devices
- 5sound/devicesI have a patch here from Leann Ogasawara that adds sysfs support for these devices. I've been lacking time to test it better, but again, it will probably make it into 2.6.1.
Is there a big rollup patch against that adds all the sys/*/dev entries for people who want to try udev?
Rob
Quoted 3 lines · Rob Landley
Is there a big rollup patch against that adds all the sys/*/dev entries for people who want to try udev?
After I get finished catching up on USB patches that people sent me for the last month, I'll generate this and post it to lkml.
thanks,
greg k-h
Quoted 2 lines · Rob Landley
Is there a big rollup patch against that adds all the sys/*/dev entries for people who want to try udev?
Oh, and you can try udev today with no kernel patches needed. All block devices and tty devices and i2c dev devices and usb major devices and v4l devices work just fine with udev on 2.6.0-test11.
thanks,
greg k-h
Quoted 5 lines · Andrew Walrond
Whats the general feeling about devfs now? I remember Christoph and others making some nasty remarks about it 6months ago or so, but later noted christoph doing some slashing and burning thereof.
Is it 'nice' yet?
The kernel code is nicer, but is is marked OBSOLETE. It also has insolvalble race conditions that have been detailed many times here on lkml in the past. Please search the archives for more info.
thanks,
greg k-h