Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Stability of /sys api

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


waltdnes at waltdnes

May 14, 2012, 12:53 AM

Post #1 of 32 (645 views)
Permalink
Stability of /sys api

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.

--
Walter Dnes <waltdnes [at] waltdnes>


ferringb at gmail

May 14, 2012, 1:43 AM

Post #2 of 32 (644 views)
Permalink
Re: Stability of /sys api [In reply to]

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


vapier at gentoo

May 14, 2012, 9:09 AM

Post #3 of 32 (637 views)
Permalink
Re: Stability of /sys api [In reply to]

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
Attachments: signature.asc (0.82 KB)


cloos at jhcloos

May 14, 2012, 9:31 AM

Post #4 of 32 (637 views)
Permalink
Re: Stability of /sys api [In reply to]

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 <cloos [at] jhcloos> OpenPGP: 1024D/ED7DAEA6


tester at gentoo

May 14, 2012, 9:56 AM

Post #5 of 32 (638 views)
Permalink
Re: Stability of /sys api [In reply to]

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
tester [at] gentoo
Gentoo Developer
Attachments: signature.asc (0.19 KB)


ciaran.mccreesh at googlemail

May 14, 2012, 10:11 AM

Post #6 of 32 (637 views)
Permalink
Re: Stability of /sys api [In reply to]

On Mon, 14 May 2012 12:56:39 -0400
Olivier Crête <tester [at] gentoo> 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
Attachments: signature.asc (0.19 KB)


waltdnes at waltdnes

May 14, 2012, 10:59 AM

Post #7 of 32 (636 views)
Permalink
Re: Stability of /sys api [In reply to]

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 <waltdnes [at] waltdnes>


cloos at jhcloos

May 14, 2012, 3:02 PM

Post #8 of 32 (635 views)
Permalink
Re: Stability of /sys api [In reply to]

>>>>> "OC" == Olivier Crête <tester [at] gentoo> 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 <cloos [at] jhcloos> OpenPGP: 1024D/ED7DAEA6


cloos at jhcloos

May 14, 2012, 3:06 PM

Post #9 of 32 (637 views)
Permalink
Re: Stability of /sys api [In reply to]

>> 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 <cloos [at] jhcloos> OpenPGP: 1024D/ED7DAEA6


gregkh at gentoo

May 14, 2012, 6:17 PM

Post #10 of 32 (636 views)
Permalink
Re: Stability of /sys api [In reply to]

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


gregkh at gentoo

May 14, 2012, 6:23 PM

Post #11 of 32 (634 views)
Permalink
Re: Stability of /sys api [In reply to]

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


mk at dee

May 14, 2012, 6:56 PM

Post #12 of 32 (643 views)
Permalink
Re: Stability of /sys api [In reply to]

On Tue, May 15, 2012 at 4:23 AM, Greg KH <gregkh [at] gentoo> 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)


williamh at gentoo

May 14, 2012, 7:13 PM

Post #13 of 32 (636 views)
Permalink
Re: Stability of /sys api [In reply to]

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


waltdnes at waltdnes

May 14, 2012, 10:05 PM

Post #14 of 32 (636 views)
Permalink
Re: Stability of /sys api [In reply to]

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 <waltdnes [at] waltdnes>


waltdnes at waltdnes

May 14, 2012, 10:55 PM

Post #15 of 32 (638 views)
Permalink
Re: Stability of /sys api [In reply to]

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 <waltdnes [at] waltdnes>


tester at gentoo

May 14, 2012, 11:32 PM

Post #16 of 32 (635 views)
Permalink
Re: Stability of /sys api [In reply to]

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
tester [at] gentoo
Gentoo Developer
Attachments: signature.asc (0.19 KB)


caneko at gmail

May 15, 2012, 1:30 AM

Post #17 of 32 (633 views)
Permalink
Re: Stability of /sys api [In reply to]

On Tue, May 15, 2012 at 1:32 AM, Olivier Crête <tester [at] gentoo> 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


gregkh at gentoo

May 15, 2012, 11:21 AM

Post #18 of 32 (634 views)
Permalink
Re: Stability of /sys api [In reply to]

On Tue, May 15, 2012 at 04:56:15AM +0300, Maxim Kammerer wrote:
> On Tue, May 15, 2012 at 4:23 AM, Greg KH <gregkh [at] gentoo> 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


gregkh at gentoo

May 15, 2012, 11:26 AM

Post #19 of 32 (635 views)
Permalink
Re: Stability of /sys api [In reply to]

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


gregkh at gentoo

May 15, 2012, 11:28 AM

Post #20 of 32 (633 views)
Permalink
Re: Stability of /sys api [In reply to]

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


mk at dee

May 15, 2012, 1:21 PM

Post #21 of 32 (633 views)
Permalink
Re: Stability of /sys api [In reply to]

On Tue, May 15, 2012 at 9:21 PM, Greg KH <gregkh [at] gentoo> 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)


waltdnes at waltdnes

May 15, 2012, 1:29 PM

Post #22 of 32 (635 views)
Permalink
Re: Stability of /sys api [In reply to]

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 <waltdnes [at] waltdnes>


nirbheek at gentoo

May 15, 2012, 1:47 PM

Post #23 of 32 (632 views)
Permalink
Re: Stability of /sys api [In reply to]

On Wed, May 16, 2012 at 1:59 AM, Walter Dnes <waltdnes [at] waltdnes> 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


waltdnes at waltdnes

May 15, 2012, 3:38 PM

Post #24 of 32 (641 views)
Permalink
Re: Stability of /sys api [In reply to]

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 <waltdnes [at] waltdnes>


sionescu at cddr

May 15, 2012, 3:44 PM

Post #25 of 32 (634 views)
Permalink
Re: Stability of /sys api [In reply to]

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
Attachments: signature.asc (0.19 KB)

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.