lkml.org 
[lkml]   [1999]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [OT] DEVFS, pros, cons, how it makes life better
Date
From
David Ford <david@kalifornia.com> said:

[...]

> four options:
> a) use devfs and don't need to mangle /dev

Inflexible; much less than what I have now.

> b) use devfs and don't agree w/ naming/perms so choose to manually modify
> /dev; use rc.whatever or devfsd

Inflexible, rc.whatever doesn't add persistence; devfsd adds a daemon for
no good reason. Fragile.

> c) don't use devfs and run MAKEDEV and don't need to mangle /dev

OK with me.

> d) don't use devfs and run MAKEDEV and don't agree w/ naming/perms and mod
> rc.whatever or /dev

What for? Permissions stay put.

> ab and cd are very similar save that ab has one less step. consider that you
> _know_ in each support call that the naming and major/minor are current.

Great! That's another reason why /dev/c0t4d2s7 is bad naming...

> > I've never said that everybody is like me. I'm careful to talk about my
> > experience, and what I have seen. As far, nobody at all has stepped forward
> > telling the grueling story of his machine with hundreds of devices that
> > change minute by minute, so I'd have to assume that this doesn't exist, or
> > in any case is so marginal that any impact at all on the kernel used by
> > millions that don't have any use for the feature is out.

> in an earlier email you point out that because you have never met anyone
> that does a certain thing that the point is moot. i am a somebody that
> does that certain thing; hot swap all day long. two nifty and very handy
> things associated with swapping pcmcia cards and usb devices.

I assume you mean connecting and disconnecting _the same devices_ a couple
of times a day. What is wrong then with allocating fixed names in /dev for
your devices? What difference is there with popping floppies/CDs/Zips in
and out, and connecting via phone to the 'net, and disconnecting? In each
of these cases the actual setting up of the device is a trivial part of the
setting up for use. If you are lazy, you write a script. I did, and it sure
isn't something I want to add into the kernel: Just too personalized, and
not used the same way always either.

devfs is touted as *the* solution for people that do that routinely to
hundreds of different devices, in random order, all day long. Again, I've
yet to see anybody in that bind.

> > > - gives sensible names to devices (c1t3d0s2 instead of sde)
> > Change MAKEDEV, be my guest.

> c1t3d0s2 will always be c1t3d0s2 whereas sde will change depending on how
> many other drives come before it. and UUID is not a workable solution
> for non-RW media.

But will be named differently when moved around among controllers. AFAIR,
some PC SCSI controllers/devices assign targets to devices in the order in
which they are on the chain. So this problem is solved halfway, if that
much. Mounting by UUID/label works even then, with much less impact.

> > > - eliminates scsi ordering problems because of sensible names

> > /dev/c1t3d0s2 becomes /dev/c2t3d0s2 when you move the controller, and
> > adding a new disk gets you to /dev/c2t4d0s2. How does this solve the
> > "sdc is now sdb" problem?

> moving the controller is one issue that remains, however most people
> appear to move drives, in my case, removable media and non-powered media
> on scsi chains changes the continuity of my drives.

You are adding them into the middle of the chain, and it hurts? Add them at
the end, case solved.

> > Check mount(8), options -L, -U for a solution to this.

> cdroms have different labels and no uuid. devfs cleanly keeps it
> ordered.

OK, and devfs automatically makes your CD with your distribution's source
appear as /dev/Source, the binaries as /dev/Install? Cool! How does it do
that?

Removable media present _exactly_ the same kind of problem as (realistic,
not "hundreds of devices that appear and disappear willy-nilly")
hotswapping. No real workable solution forthcoming for removable media
after all these years should tell you something...

> > > - completely eliminates major/minor number problems

> > Can't do that, because it is deeply ingrained into the kernel's way of
> > handling devices.

> and devfs is a direction away from them.

Assuming major/minor is really a bad idea, devfs is just one way to move
away from them. To do that, it adds quite a lot of complexity, which is
very bad.

> > > - moves naming complexity INTO USER SPACE (good for usb)
> > MAKEDEV is user space.

> manual v.s. automatic

Manual policy. Policy can't be automatic.

> > > - user space scripts ran on insertion (just like cardmgr/PCMCIA)
> > Can be done (sort of) with modules and pre- post- scripts. Not nice.

> similar to kmod, no? devfsd again can be like quota utils and update an
> incore map.

OK.

> > > - UNIX-like /dev without UNIX-like rw fs (good for embedding on romfs)
> > ROMFS is designed to be _small_, not full-Unix. I'd guess adding device
> > nodes to ROMFS won't make it much larger. Surely much less than devfs and
> > its bloat in all devices by itself.

> devfs is not bloated.

devfs _has_ a cost: in the kernel, in each device, in daemons.

> > > - provides a proper namespace (no need for recent rash of /proc/*/dev)
> > If you can't provide a proper namespace in /dev, then doing it as a fake
> > filesystem is out anyway.

> let's wonder for a bit. i am a developer of a widget. i change my
> major/minor for my widgets. i don't have to go update MAKEDEV and make a
> big notice to everyone. /dev will always have the naming constructs that
> i use in my code.

And I as a developer for gizmos have to go searching all over the kernel
source so my naming and major/minor don't conflict with anybody else's. I'd
assume updating MAKEDEV is a bit easier.

> > > Notice that all of these problems can be solved in other ways (for
> > > example you can solve the sde -> c1t3d0s2 problems using a startup
> > > script, similar to how Solaris populates /dev) but devfs solves ALL
> > > of the problems in one fell swoop.

> > That isn't exactly right. As said above, it does not solve all problems.
> > Plus the naming problem is still there, it is just shifted from MAKEDEV
> > (yuck!) to either another configuration file (same yuck!) or the driver

> in my case, i have never needed devfsd. in an earlier email you managed
> to make a large action list for the kernel and devfsd to talk and update
> confs. look toward quota and see how it interacts with on disk files and
> in core. start up and shut down are your disk factor. nothing else
> unless you choose to sync. i don't know of many people that lmbench
> startup and shutdown.

Well, many people complain that startup/shutdown takes way too long right
now... Also, in the case of quotas what is recorded in the quota file are
static limits, the in-core structure keeps track of actual disk usage. The
in core devfs structure will have to be written out _each time_ the system
goes down. Even by unplugging it. This because you want to record
changeable information in it, critical information that _has_ to survive
reboots. No buts or ifs there.

> > unless you prefer to live in a vacuum. Also, if something solves several
> > problems in one fell swoop _without_ adding strange klugdes and needing
> > extra machinery, it's an elegant solution (the conception behind Unix is a

> how many iterations of the F00F bug solution did we run through? how
> many times has the way SMP been done in the kernel been changed, or VM,
> or VFS?

Several. And F00F costs nothing in runtime, a trivial amount in RAM. SMP
hast't gone through iterations, it started crude and is being refined. VFS
has been worked over a few times, getting faster each time.

devfs was considered and rejected. A solution for the hotplugging problem
is being sought right now, devfs clearly doesn't cut it by far.

> "version 1" normally leads to "version 2".

"version 0.1" (devfs) came out far short, didn't get even to "1". Next
candidate for "version 1" is being sought.

[...]

> > fine example). If not, it's just exchanging one mess for another one. My
> > fear here is that devfs exchanges an acknowledged mess, which we know and
> > over time learned how to handle in a reasonable way; with a much larger
> > mess, one with unknown quirks that will have to be worked around. All for
> > no real gain.

> i compile new kernels several times a day for the hundreds of systems
> worldwide that we manage. devfs has enabled me to save a few minutes
> here and there frequently and not worry about /dev updates. over time,
> that translates to a l ot of saved time. i've been using devfs for over
> a year now and i honestly say that i don't worry about /dev and my
> troubles with adding devfs to the kernel a re by large "patch -p1 <
> devfs...". that's a trouble i can sleep with most easily.

I just wonder how screwing around with devfs is less work than distributing
a /etc/rc.d/rc.devices script that sets up all devices as you see fit on
bootup if that is what worries you so. What the extra cost over hundreds of
machines is of the wasted memory and CPU cycles that go into devfs. OTOH,
IIUC, this is exactly what you have to do anyway if you want devfs to work
at all...

> > Yes, I did. But if the costs involved are smaller than the benefits, go for
> > it. If not, leave it alone. In this case, as no pressing need has surfaced,
> > and no clear benefits have been shown, leave it alone.

> many of my peers use devfs and none of us have issues to deal with. the
> costs involved to date are a small amount of time during the week for one
> man, Richard. for the work that he has done, my benefits mean saving
> time personally and a significantly lower accumulated load for that one
> class of servers that stats /dev/ a lot.

You don't have to handle it, others do. I don't have to handle it either,
and Richard doesn't have to spend a minute a year on my problems right
now. If devfs becomes more than the current extraofficial patch that some
few use, the support load _will_ go up, and not be a few minutes a week
anymore.

What class of servers is that? How much of a difference does it make? Each
call, overall as a percentage of the load of the server? Are you sure that
the latest workovers given to the filesystem don't make any differences
there dissapear in the noise?

> for you the benefits aren't clear and for me the benefits are very clear.
> it solves a variety of little issues. little issues compounded by
> numerous systems makes for a lot of frustration and time.

And introduces a bunch of major issues in the process.

> we have a bunch of stuff in the kernel such as AX.25 and IPX because it
> benefits someone. i'm probably correct in that they don't benefit you.

Right.

> nor do they benefit me. but i will staunchly support them just as i do
> devfs.

IPX, AX.25, DECnet, SNA, SMB and such are forced on us to interact with
more or less broken other systems. The miriard device drivers in the kernel
are needed to be able to use various devices over which Linux has no
control. devfs isn't needed in any of those ways at all.
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile +56 32 672616


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.214 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site