lkml.org 
[lkml]   [1999]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UUIDs (and devfs and major/minor numbers)
   Date: 	Fri, 18 Jun 1999 18:17:16 -0400
From: "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>

We're all pretty much agreed that device major and minor numbers are
something of a problem, especially when it comes to hot-pluggable devices.
So what alternatives might there be?

Actually, I'm not convinced that major/minor numbers are the problem.
Right now we have our choice between statically allocated major/minor
numbers, which admittedly can be a problem because you have to deal with
a central registry (although I don't that problem is *that* bad yet!),
or purely dynamic major numbers which have the problem that it's hard to
create the devices with the correct major number. (Althoguh this
problem can be solved; I dealt with it in the Comtrol Rocketport
driver's rc.d script, before I got a statically allocated major number.)

Having a range of major numbers which are assigned dynamically isn't
really a problem if you have a user-mode daemon which can deal with
creating the devices if necessary. (And I think almost everyone
participating in this discussion recognizes that having a user-mode
daemon is a good and useful strategy.) The kernel and the user-mode
daemon can also (without not much difficulty) connive to make sure that
when a device disappears from a system and plugged back in later, that
the same major number is reused.

I do agree with you having having a unique string-based,
self-descriptive device ID is a good thing, but instead of using that ID
*instead* of the major/minor devices, why not have the kernel export a
mapping table between the string ID and the major/minor devices to the
user mode daemon, and then letting the user mode deamon crate the
appropriate device files if necessary? This solves the NFS backwards
compatibility problem, for example.

It also deal with the problem that symlinks into /devices doesn't solve:
the permissions problem. By using real, traditional block/character
mode device files in /dev, we can solve the ownership/group/permissions
problem extremely easily.

As far as trying to find all of the CD-ROM's present in the system, or
all of the some particular type of device, if applications really badly
need this sort of thing, it's a really bad idea to tell them that they
can do this by scanning /dev in some fashion. That would lock us into
that way of doing things forever. Instead, we should specify and
publish a general API for doing this! That way, if we later decide that
we want to change how to obtain that information, we can change a shared
library without having to force all of the application programs to
recode their programs.

If we use this approach, it also means that we can also solve the
problem for existing systems by having that API (let's call it the
device-lookup API) consult a static file (or set of files) to find the
information which cdparanoia or some other application wants. It would
also be trivial to make the PCMCIA manager edit that file when a PCMCIA
CD-ROM drive was inserted or removed into the system. This would allow
applications to have the benefits of such an API right away, without
having to wait for 2.4, or some more complicated scheme (whether it be
devfs or -- I hope --- something cleaner) to be deployed into the
mainstream kernel.

- Ted

-
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:52    [W:0.147 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site