Re: [gentoo-dev] Stability of /sys api
On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: I *DON'T WANT* a serious framework, I want a lightweight device manager... period... end of story. Stick with the unix principle of one app doing one thing well. mdev is enough for the vast majority of people. For the people who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware, I'm sure mdev is fine. A static /dev is even fine for you probably. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 1:32 AM, Olivier Crête tes...@gentoo.org wrote: On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: I *DON'T WANT* a serious framework, I want a lightweight device manager... period... end of story. Stick with the unix principle of one app doing one thing well. mdev is enough for the vast majority of people. For the people who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware, I'm sure mdev is fine. A static /dev is even fine for you probably. I agree. And I don't believe people who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware qualify as the vast majority of people. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 04:56:15AM +0300, Maxim Kammerer wrote:
On Tue, May 15, 2012 at 4:23 AM, Greg KH gre...@gentoo.org wrote:
We learned that this is not a good idea at all, and should be left to
userspace helper applications
that listen for dbus messages.
Could you perhaps expand a bit on those reasons? E.g., I had good
experience with the following short script for coupling udev events
with autofs:
https://github.com/mkdesu/liberte/blob/master/src/usr/local/sbin/ps-mount.
Gentoo wiki has a similar tutorial as well. Granted, it is a
single-user setup, but I can imagine it being extended to work with
ConsoleKit. One obvious problem is mounting encrypted volumes. I
thought about moving to e.g., udisks-glue (as a more standard
solution), but from what I hear there are too many bugs with udisks at
the moment.
I know of no such problem with udisks, have you reported them to the
upstream developers?
Yes, encrypted disks are one such problem, other bad things happen when
you hit a disk with bad sectors, and other fun things. You can stall
the whole hotplug path, causing issues and overruns.
For more details as to why this is a bad idea, see the linux-hotplug
mailing list archives, it was covered in detail there a few years ago.
Actually with all the hype about mdev these days, why not just use a 3
year old version of udev (or maybe 4), that is probably what mdev is at
as far as functionality goes.
I don't know at what state udev was 3 or 4 years ago, but mdev can:
1. Populate /dev (now unnecessary due to devtmpfs).
udev can't even do that these days (see, udev got smaller), as devtmpfs
is what needs to do this.
Right there, if that's all you need, and it's what most embedded systems
need, udev isn't even needed, just use devtmpfs and all is fine.
2. Handle ownership, permissions and symlinks to /dev nodes once they
appear, according to simple rules (can be probably done with inotify).
Careful about user ownerships of multi-user machines, that gets tricky.
3. Act as /sbin/hotplug, typically doing something equivalent to this
one-liner:
[ ${ACTION} = add -a -n ${MODALIAS} ] modprobe -qb ${MODALIAS}
Oh wow. Your /proc/sys/kernel/hotplug file should be set to if you
want any chance to have a fast boot process.
So, using mdev you slow your boot down, and slow down the response time
from uevents. I don't think that's what you really want for a
lightweight system :)
I don't think mdev can do anything else. Building any serious
framework on top of mdev seems pointless to me, since it will probably
end up as a small subset of udev core reimplemented with scripts.
Again, what's wrong with just using udev for this as-is? What benifit
can mdev provide you over udev? Is it somehow smaller? How small?
It's obviously not faster due to the forking required from
/sbin/hotplug, so that can't be a good reason to prefer it.
thanks,
greg k-h
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 01:55:23AM -0400, Walter Dnes wrote: On Mon, May 14, 2012 at 06:23:36PM -0700, Greg KH wrote So you need to implement stuff such that you are not dependant on the bus type. If you see a new disk, act on it, it's that simple. But note, please do not be automounting disks from uevents directly. After some more Google-searching. it looks like the official channels way is via /etc/mdev.conf. Note that this is on a system with busybox[mdev] and no udev. /etc/mdev.conf has a rudimentary set of mdev rules abilities, and most importantly, it can also call external executables (scripts/programs/whatever). On my mdev based machines... $ cat /proc/sys/kernel/hotplug /sbin/mdev Oh my, don't do that. Please. It will slow your machine down, and on some systems, and devices, cause fork-bombs causing your box to come to a crawl and potentially die. There's also ordering issues that the called program needs to resolve to get things right that add lots of logic and slowdowns at times. I really want to get rid of that entry and option from the kernel entirely, but need to keep it due to legacy systems and API issues. But really, don't do that, it's not a good idea at all. Actually with all the hype about mdev these days, why not just use a 3 year old version of udev (or maybe 4), that is probably what mdev is at as far as functionality goes. Why not just fork udev from then and go forward from that? What exactly are you not liking in udev that makes you want to get rid of it so badly? What is it doing that bothers people so much? Unfortunately, I am not a C programmer, so forking udev is only a dream. As Maxim has pointed out, mdev does what most people need. As does udev. And udev is faster, and I'd bet, the same size. The busybox people do the maintenance. Given their target audience (embedded and lightweight systems), we can be certain that mdev won't grow into a monstrosity. Even if I could do it, why reinvent the wheel? We have a perfectly usable alternative right now in mdev. mdev is the reinvention, but hey, if you want it, that's fine. Embedded and lightweight systems don't even need mdev or udev, they just use the kernel-provided devtmpfs and all is good. But it's your choice, and that's great, but please be aware of the tradeoffs you are choosing, and again, my worry about using a /sbin/hotplug executable is real and should be resolved. What specifically is your objection to udev today? Is it doing things you don't like? Too big? Something else? thanks, greg k-h
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 01:05:57AM -0400, Walter Dnes wrote:
On Tue, May 15, 2012 at 04:56:15AM +0300, Maxim Kammerer wrote
I don't know at what state udev was 3 or 4 years ago, but mdev can:
1. Populate /dev (now unnecessary due to devtmpfs).
2. Handle ownership, permissions and symlinks to /dev nodes once they
appear, according to simple rules (can be probably done with inotify).
3. Act as /sbin/hotplug, typically doing something equivalent to this
one-liner:
[ ${ACTION} = add -a -n ${MODALIAS} ] modprobe -qb ${MODALIAS}
That's *EXACTLY* what I want and need. To borrow an old emacs joke,
udev is a mediocre OS that lacks a lightweight device manager.
Huh? How is udev not lightweight? What does it have in it that makes
it heavy? I see lots of things in mdev that make it heavier and
slower than udev :)
I don't think mdev can do anything else. Building any serious
framework on top of mdev seems pointless to me, since it will probably
end up as a small subset of udev core reimplemented with scripts.
I *DON'T WANT* a serious framework, I want a lightweight device
manager... period... end of story. Stick with the unix principle of one
app doing one thing well. mdev is enough for the vast majority of people.
I don't see how udev isn't a do one thing really well program and pass
off to others, piping data to programs that can do other things to it if
wanted/needed. Can you explain how it violates this Unix maxium?
thanks,
greg k-h
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 9:21 PM, Greg KH gre...@gentoo.org wrote: I know of no such problem with udisks, have you reported them to the upstream developers? As I said, it's just what I hear — perhaps it's the usual retrograde whining. I should probably just try udisks-glue, the only issue I see is that it depends on UDisks 1. You can stall the whole hotplug path, causing issues and overruns. Note that the script I mentioned immediately forks, and only updates autofs mapping entries — it doesn't actually mount anything. Right there, if that's all you need, and it's what most embedded systems need, udev isn't even needed, just use devtmpfs and all is fine. Perhaps I wasn't expressing myself clearly — the point was to show that mdev is not needed. I used mdev in initramfs previously, but now rely on devtmpfs and the one-liner /sbin/hotplug for loading modules. Incidentally, turning off mdev resulted in Busybox executable size change of precisely 0, which I guess shows how much mdev actually does. I really want to get rid of that entry and option from the kernel entirely Please don't — it's useful in Busybox-based initramfs. Dracut-like inclusion of udev and its dependencies DAG is usually unnecessary and an overkill. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 02:32:57AM -0400, Olivier Cr?te wrote On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: I *DON'T WANT* a serious framework, I want a lightweight device manager... period... end of story. Stick with the unix principle of one app doing one thing well. mdev is enough for the vast majority of people. For the people who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware, I'm sure mdev is fine. A static /dev is even fine for you probably. Huh!?!?!? USB sticks work just fine, thank you, with mdev. I also regularly backup my mdev-based machine via rsync to an external drive via USB. And yes my camera does show up as a USB mass storage device. Ditto for my HTC Desire. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Stability of /sys api
On Wed, May 16, 2012 at 1:59 AM, Walter Dnes waltd...@waltdnes.org wrote: On Tue, May 15, 2012 at 02:32:57AM -0400, Olivier Cr?te wrote On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: I *DON'T WANT* a serious framework, I want a lightweight device manager... period... end of story. Stick with the unix principle of one app doing one thing well. mdev is enough for the vast majority of people. For the people who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware, I'm sure mdev is fine. A static /dev is even fine for you probably. Huh!?!?!? USB sticks work just fine, thank you, with mdev. I also regularly backup my mdev-based machine via rsync to an external drive via USB. And yes my camera does show up as a USB mass storage device. Ditto for my HTC Desire. Those who don't understand UNI^H^H^Hsoftware are condemned to reinvent it, poorly. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote On Tue, May 15, 2012 at 01:55:23AM -0400, Walter Dnes wrote: After some more Google-searching. it looks like the official channels way is via /etc/mdev.conf. Note that this is on a system with busybox[mdev] and no udev. /etc/mdev.conf has a rudimentary set of mdev rules abilities, and most importantly, it can also call external executables (scripts/programs/whatever). On my mdev based machines... $ cat /proc/sys/kernel/hotplug /sbin/mdev Oh my, don't do that. Please. It will slow your machine down, and on some systems, and devices, cause fork-bombs causing your box to come to a crawl and potentially die. There's also ordering issues that the called program needs to resolve to get things right that add lots of logic and slowdowns at times. I really want to get rid of that entry and option from the kernel entirely, but need to keep it due to legacy systems and API issues. But really, don't do that, it's not a good idea at all. During bootup, mdev is invoked as mdev -s, and in hotplug mode it's simply mdev. In hotplug mode, mdev returns some environmental variables, specifically ACTION, which are not returned by mdev -s. Any scripts launched by mdev can easily figure out whether they've been called at bootup or in response to a hotplug event, and act accordingly. A Google search turns up many hits about instructions for automounting under mdev, and it appears relatively easy. What specifically is your objection to udev today? Is it doing things you don't like? Too big? Something else? Today, it requires an initramfs if /usr is not physically on /. That is due in large part to the fact that it has been rolled into the systemd tarball, and inherited some of systemd's code and limitations, despite the fact that udev is still a separate binary. That's today. How long before it becomes part of the systemd binary? -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Stability of /sys api
On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote: On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote What specifically is your objection to udev today? Is it doing things you don't like? Too big? Something else? Today, it requires an initramfs if /usr is not physically on /. That is due in large part to the fact that it has been rolled into the systemd tarball, and inherited some of systemd's code and limitations, despite the fact that udev is still a separate binary. This is absolutely and definitely false. Where did you hear such nonsense ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stability of /sys api
On Wed, May 16, 2012 at 12:44:59AM +0200, Stelian Ionescu wrote On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote: On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote What specifically is your objection to udev today? Is it doing things you don't like? Too big? Something else? Today, it requires an initramfs if /usr is not physically on /. That is due in large part to the fact that it has been rolled into the systemd tarball, and inherited some of systemd's code and limitations, despite the fact that udev is still a separate binary. This is absolutely and definitely false. Where did you hear such nonsense ? 1) Did you sleep through the /usr and initramfs flamewars? http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken 2) The udev sources have merged into the systemd tarball. See... http://article.gmane.org/gmane.linux.hotplug.devel/17392 And note the date is April 3rd, not April 1st. If they were really as worried about compatability as they claim, you wouldn't need to use initramfs for udev with a separate /usr. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Stability of /sys api
I asked what I thought was a simple developer-type question. I don't want this to become a public flamewar. If anybody wants to discuss the issue with me further, please email directly to me and not the list. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 07:51:03PM -0400, Walter Dnes wrote: On Wed, May 16, 2012 at 12:44:59AM +0200, Stelian Ionescu wrote On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote: On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote What specifically is your objection to udev today? Is it doing things you don't like? Too big? Something else? Today, it requires an initramfs if /usr is not physically on /. That is due in large part to the fact that it has been rolled into the systemd tarball, and inherited some of systemd's code and limitations, despite the fact that udev is still a separate binary. This is absolutely and definitely false. Where did you hear such nonsense ? 1) Did you sleep through the /usr and initramfs flamewars? http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken 2) The udev sources have merged into the systemd tarball. See... http://article.gmane.org/gmane.linux.hotplug.devel/17392 And note the date is April 3rd, not April 1st. If they were really as worried about compatability as they claim, you wouldn't need to use initramfs If you saw my last message on this subject, there is no need to use initramfs if you don't want to use it. See the sep-usr use flag on the ~arch version of busybox and the instructions you get when you turn that on. William pgpHlUscQM0LF.pgp Description: PGP signature
Re: [gentoo-dev] Stability of /sys api
On 16 May 2012 05:21, Walter Dnes waltd...@waltdnes.org wrote: On Wed, May 16, 2012 at 12:44:59AM +0200, Stelian Ionescu wrote On Tue, 2012-05-15 at 18:38 -0400, Walter Dnes wrote: On Tue, May 15, 2012 at 11:26:03AM -0700, Greg KH wrote What specifically is your objection to udev today? Is it doing things you don't like? Too big? Something else? Today, it requires an initramfs if /usr is not physically on /. That is due in large part to the fact that it has been rolled into the systemd tarball, and inherited some of systemd's code and limitations, despite the fact that udev is still a separate binary. This is absolutely and definitely false. Where did you hear such nonsense ? 1) Did you sleep through the /usr and initramfs flamewars? http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken You seem to have missed the bit that this has nothing at all to do with systemd. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Stability of /sys api
On 15/05/12 21:07, Arun Raghavan wrote: 1) Did you sleep through the /usr and initramfs flamewars? http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken You seem to have missed the bit that this has nothing at all to do with systemd. I guess the systemd in the url might be have people consider it a sort of tell-tale. It could had been http://bluez.org/known_issue/separate-usr-problems Maybe. -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 03:53:53AM -0400, Walter Dnes wrote: After some Google-searching, I think I've figured out how to implement automounting under mdev. I'd like to put in as much sanity-checking into the script as possible. Right now I have 1 USB stick plugged in as /dev/sdb. Th hard drive is /dev/sda. The removable data is readable like so... cat /sys/block/sda/removable 0 cat /sys/block/sdb/removable 1 My question... is this API stable or deprecated? I.e. can I count on it being around for a while? I figure this question is a developer type question rather than ordinary user type. Api is stable although last I dealt with that crap it was reliant on chipsets/controllers not sucking and misreporting (mmc in particular comes to mind, although perhaps the hardware sucks less these days). Suggest you start studying udev source in addition since your questions of that sort are likely to be answered there. Aka, most likely wind up asking udev upstream (likely gregkh assuming he hasn't killfile'd everyone from that thread). Now the unfun part; this isn't really the right place to be asking. I get you're doing this w/ a gentoo intent, but you're dancing that line mightily fine. People asking can I safely use nested context managers in python2.6 even if it's orientated towards a potential gentoo bit (say the ephemeral gentoo stats project), typically will be told dunno. Ask the people who wrote the damn thing. Point there is that the ml shouldn't be used as tech help for the guts of I don't want udev and am trying to replace it with mdev; pkgcore nor paludis internal questions don't come here (format does since this is the appropriate venue) under the same logic. Forums come to mind, or appropriate upstreams as mentioned. Barring that, use the source luke, and start reading the lkml. If you're trying to do this, you'll likely need to track discussions there. Not trying to be a dick mind you, and perhaps others view othewise, but this isn't the place for it nor do I suspect people care to see more of this particular war play out on our ml. ~harring
Re: [gentoo-dev] Stability of /sys api
On Monday 14 May 2012 03:53:53 Walter Dnes wrote: My question... is this API stable or deprecated? I.e. can I count on it being around for a while? I figure this question is a developer type question rather than ordinary user type. if userspace is relying on stuff in /sys, then it's part of the ABI -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Stability of /sys api
WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Stability of /sys api
On Mon, 2012-05-14 at 12:31 -0400, James Cloos wrote: WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. And I'm sure it works fine with udev? Those who do not understand udev are condemned to reinvent it, poorly. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stability of /sys api
On Mon, 14 May 2012 12:56:39 -0400 Olivier Crête tes...@gentoo.org wrote: On Mon, 2012-05-14 at 12:31 -0400, James Cloos wrote: WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. And I'm sure it works fine with udev? I dunno. Internet Explorer broke and now udev won't run. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 12:31:25PM -0400, James Cloos wrote WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. You're right. Same for me. Thanks for pointing it out. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Stability of /sys api
My USB drive reports 0. WD You're right. Same for me. Thanks for pointing it out. The removable flag specifies whether the drive has removable media; before flash drives only things like floppy, optical, zip, etc drives had removable==1. It also would be accurate for flash card readers. If thumb drives specify it, then they lie. The flag is read from the drive's metadata. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Stability of /sys api
OC == Olivier Crête tes...@gentoo.org writes: OC And I'm sure it works fine with udev? It automounts when plugged in, if that is what you mean. (In fact each partition does; the one in fstab(5) where it should and the one not in fstab in a mount point based on its label.) And the dev files get removed when the drive is unplugged. (unplugged here means either the usb cable or the power cable.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 12:09:23PM -0400, Mike Frysinger wrote: On Monday 14 May 2012 03:53:53 Walter Dnes wrote: My question... is this API stable or deprecated? I.e. can I count on it being around for a while? I figure this question is a developer type question rather than ordinary user type. if userspace is relying on stuff in /sys, then it's part of the ABI Yes, but note, you are looking at the wrong thing, what you are reading isn't really what you think it means... And to rely on sysfs, you have to be very careful, you can not rely on position, or files, always being where you saw them yesterday as device ids, topologies, and other stuff, change all the time. greg k-h
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 03:53:53AM -0400, Walter Dnes wrote: After some Google-searching, I think I've figured out how to implement automounting under mdev. I'd like to put in as much sanity-checking into the script as possible. Right now I have 1 USB stick plugged in as /dev/sdb. Th hard drive is /dev/sda. The removable data is readable like so... cat /sys/block/sda/removable 0 cat /sys/block/sdb/removable 1 My question... is this API stable or deprecated? I.e. can I count on it being around for a while? I figure this question is a developer type question rather than ordinary user type. You might want to look at Documentation/ABI/ in the kernel source tree if you are curious about sysfs files like this. As you have figured out, this really doesn't mean what you think it does. In fact, there's no way to determine what I think you are asking for, which is can this disk go away, as really, any disk can go away at any point in time, just like any disk can show up at any point in time as well. Think PCI hotplug systems, thunderbolt, pcmcia, ExpressCard, Firewire, USB, SCSI, etc. So you need to implement stuff such that you are not dependant on the bus type. If you see a new disk, act on it, it's that simple. But note, please do not be automounting disks from uevents directly. As someone else said on this thread, those that have not learned from the lessons of udev, will implement it poorly. We learned that this is not a good idea at all, and should be left to userspace helper applications that listen for dbus messages. Both GNOME and KDE work this way quite well, so I would be very wary of reimplementing the wheel. Actually with all the hype about mdev these days, why not just use a 3 year old version of udev (or maybe 4), that is probably what mdev is at as far as functionality goes. Why not just fork udev from then and go forward from that? What exactly are you not liking in udev that makes you want to get rid of it so badly? What is it doing that bothers people so much? Good luck, greg k-h
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 4:23 AM, Greg KH gre...@gentoo.org wrote:
We learned that this is not a good idea at all, and should be left to
userspace helper applications
that listen for dbus messages.
Could you perhaps expand a bit on those reasons? E.g., I had good
experience with the following short script for coupling udev events
with autofs:
https://github.com/mkdesu/liberte/blob/master/src/usr/local/sbin/ps-mount.
Gentoo wiki has a similar tutorial as well. Granted, it is a
single-user setup, but I can imagine it being extended to work with
ConsoleKit. One obvious problem is mounting encrypted volumes. I
thought about moving to e.g., udisks-glue (as a more standard
solution), but from what I hear there are too many bugs with udisks at
the moment.
Actually with all the hype about mdev these days, why not just use a 3
year old version of udev (or maybe 4), that is probably what mdev is at
as far as functionality goes.
I don't know at what state udev was 3 or 4 years ago, but mdev can:
1. Populate /dev (now unnecessary due to devtmpfs).
2. Handle ownership, permissions and symlinks to /dev nodes once they
appear, according to simple rules (can be probably done with inotify).
3. Act as /sbin/hotplug, typically doing something equivalent to this one-liner:
[ ${ACTION} = add -a -n ${MODALIAS} ] modprobe -qb ${MODALIAS}
I don't think mdev can do anything else. Building any serious
framework on top of mdev seems pointless to me, since it will probably
end up as a small subset of udev core reimplemented with scripts.
--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 06:23:36PM -0700, Greg KH wrote: Actually with all the hype about mdev these days, why not just use a 3 year old version of udev (or maybe 4), that is probably what mdev is at as far as functionality goes. Why not just fork udev from then and go forward from that? What exactly are you not liking in udev that makes you want to get rid of it so badly? What is it doing that bothers people so much? I'm wondering the same thing since once busybox 1.20.0 hits stable you will be able to have a separate /usr without an initramfs quite easily if that's what you want to do. When you emerge this version of busybox with the sep-usr use flag, you get a binary in / called ginit. Now just follow the instructions you got when you emerged it. William pgpsDOJ63MLdp.pgp Description: PGP signature
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 04:56:15AM +0300, Maxim Kammerer wrote
I don't know at what state udev was 3 or 4 years ago, but mdev can:
1. Populate /dev (now unnecessary due to devtmpfs).
2. Handle ownership, permissions and symlinks to /dev nodes once they
appear, according to simple rules (can be probably done with inotify).
3. Act as /sbin/hotplug, typically doing something equivalent to this
one-liner:
[ ${ACTION} = add -a -n ${MODALIAS} ] modprobe -qb ${MODALIAS}
That's *EXACTLY* what I want and need. To borrow an old emacs joke,
udev is a mediocre OS that lacks a lightweight device manager.
I don't think mdev can do anything else. Building any serious
framework on top of mdev seems pointless to me, since it will probably
end up as a small subset of udev core reimplemented with scripts.
I *DON'T WANT* a serious framework, I want a lightweight device
manager... period... end of story. Stick with the unix principle of one
app doing one thing well. mdev is enough for the vast majority of people.
--
Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 06:23:36PM -0700, Greg KH wrote So you need to implement stuff such that you are not dependant on the bus type. If you see a new disk, act on it, it's that simple. But note, please do not be automounting disks from uevents directly. After some more Google-searching. it looks like the official channels way is via /etc/mdev.conf. Note that this is on a system with busybox[mdev] and no udev. /etc/mdev.conf has a rudimentary set of mdev rules abilities, and most importantly, it can also call external executables (scripts/programs/whatever). On my mdev based machines... $ cat /proc/sys/kernel/hotplug /sbin/mdev Actually with all the hype about mdev these days, why not just use a 3 year old version of udev (or maybe 4), that is probably what mdev is at as far as functionality goes. Why not just fork udev from then and go forward from that? What exactly are you not liking in udev that makes you want to get rid of it so badly? What is it doing that bothers people so much? Unfortunately, I am not a C programmer, so forking udev is only a dream. As Maxim has pointed out, mdev does what most people need. The busybox people do the maintenance. Given their target audience (embedded and lightweight systems), we can be certain that mdev won't grow into a monstrosity. Even if I could do it, why reinvent the wheel? We have a perfectly usable alternative right now in mdev. My main programming strength is bash scripts etc. Actually, a fork I'd be interested in would be to take standard Gentoo and replace as many programs as possible with their busybox-symlink equivalants. This would require at least a new profile, to a) create the appropriate symlinks, and b) not pull in the standalone versions. -- Walter Dnes waltd...@waltdnes.org
