> Again, how many _different_ kinds of devices will I be using simultaneously
> on it? What kind of iBook devices plug themselves in, just by themselves,
> and get instantly useable without any user intervention?
This is EXACTLY the point here: "why this wonderfull superpowerfull computer
need MORE actions from me then just plugging the device ? I ALREADY done all
what's need from me: I plugged brand new USB camera in port -- why I can not
use it without those stupid mknod ???"... Yes, not all users are like this and
it's not always desirable but there are MILLIONS of users like this anyway...
>> > > H> Reasons for devfs:
>> > > H> - Makes handling hot-plug easier, but marginally so
>> > > H> - Unclutters /dev
>> > > A static /dev doesn't scale. That's why IRIX 6.4+ uses a hybrid
>> > > dynamic /dev. I presume that Sun does it for similar reasons.
> Irix does it, Solaris does it too, ... I know the Solaris one, and don't
> like it: You must reboot to get new devices attached.
This EXACTLY since there are NOT devfs but hybrid scheme.
> Also, devices change their names if I move them around.
Your solutin to this problem is to create the same names by hand when device
is moved, of course ? With devfs you can do a symlink.
> Kernel mechanism itself seems quite minimal (run a couple of userspace
> programs on startup when given '-r', no big deal).
And then we need to reboot to get new devices attached :-) Exactly.
> Sure, /dev is uncluttered. As long as you remember doing the '-r' each time.
Just to keep /dev "Unix-like" :-)
> I just load up the machine, do the '-r' thing and forget
> about it. A few files too much inside /dev (where I rarely go) isn't a big
> deal.
1. Few thousands files.
2. You MUST issue mknod when attaching new device. It's problem for A LOT OF
users. The ones who are sure that cores are inside of some fruits :-)
> Besides, it is the easiest way to get persistence.
The price you named: "-r" and reboot when attaching new device. Not acceptable
for a lot of users.
>> > - Impact on kernel drivers (discussed above)
>> None.
> "No changes", "10 extra lines for each driver", "my driver was simpler
> because of devfs" are all claims made here.
And all are true. Unmodified driver will work with devfs, 10 extra lines
will add standard name for that driver when plugged and you can do quite a
few things with devfs not imaginable without it.
> Note the last one: If true,
100% true.
> that driver will _force_ devfs, as it won't work otherwise.
If driver writer will do it that way.
> So "just #ifdef it to nil" won't work.
>> > - Impact on future developments: Say capability-enabled root-less Linux
>> > distributions. How will capabilities be handled for devices? Now there
>> > will have to be an all-powerful device manager... want to bet what
>> > crackers will start to try at after getting into your system?
>> That would be how capabilities are managed. That thread convinced me
>> that capabilities are enforced in kernel space, but held in user
>> space. And this is worse than the current system in what way?
> Capabilities can not be handled in user space. If they are, they are next
> to useless: The kernel won't be able to distinguish a faked capability
> handler from the real one, and the security you should get goes out the
> window.
Of course capability can be handled in userspace. Hint: root also acts in
userspace.
> Same with permissions on devices: They have to be handled in the
> kernel, as they are way to important to be handled outside by insecure means.
There are enough vital programs in userspace anyway (init, for example :-)
If you can not trust them you should not use Linux at all.
>> > Again, /dev might not scale well, but it is a non-problem. I have yet to
>> For you.
> And everybody else I've ever met.
I'm had problem with 16 partitions only limattion. And it's even before
USB is widely used...
>> > see a machine with hundreds of devices. And the network around here, that
>> I have.
> Great! How is it handled? What percentage of the admin time goes into
> managing devices? 1%? 0.1%? Less? More? 10%? 20%?
What if there are NO admin ? So even 0.0001% is non-acceptable. Home computer
for my grandmother. I need two days to trawell to her and she can not use
mknod for sure.
>> > is certainly made of hundreds of devices, isn't reconfigured willy-nilly.
>> Some need to be.
> Which ones? Why? How is that managed now? How will a simple naming scheme
> for devices make the work simpler? By how much?
It's make "compurter for grandmother" possible. Not alone, of course. But
it's needed ingridient.
>> > Each change does take some work figuring out how it works and then changing
>> > it. Naming issues (and that is the _only_ thing a devfs can solve) is a
>> > very minor part here.
>> devfs solves so many more problems than "naming issues" that this isn't
>> even funny.
> WHAT problems, exactly, does devfs (which is just a naming scheme) solve?
Read devfs FAQ. It's described there in details.
>> > And yet again, I do see some advantages in a devfs type system. It's just
>> > that they are very minor, IMO, and just not worth the extra hassle. No, not
>> > extra hassle for the systems user or even administration, hassle for the
>> > developers. But that one, soner or later, translates into extra hassle for
>> > the former. Software systems developments in general have shown time and
>> > again that "just a few percent here" ends adding up to a huge, unmanageable
>> > ammount. Just read Fred Brook's "The Mythical Man Month", or closer to hand
>> > look at into what sorry state the neverending quest for new features got
>> > the mass software industry in general. Linus has taken this to hearth, he
>> > won't allow "a few percent less here for a possible gain there", or "cool
>> > features, just for their coolness" into the kernel.
>> devfs stands to _save_ a lot of work for developers by freeing them up
>> from how to manage the next set of dynamic devices. The people that seem
>> to be arguing against it the loudest are the Admins who would have
>> to change a few lines in their scripts to account for a consistent
>> /dev at boot time.
> There is yet to be the "first set of dynamic devices" (USB), the discussion
> started precisely on how to handle them. If devfs really did solve all, the
> discussion would not even have started. That it did shows precisely that
> devfs does _not_ solve the issues involved.
No. It shows that someone even not read devfs FAQ before arguing against it.
-
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/