On Sun, 23 Apr 2000, Richard Gooch wrote:
> Manuel Estrada writes:
> > Attached come a couple of ideas which came to my mind last
> > night. As I don't follow lkml too closely, they may be obsolete; if
> > that is the case I apologize.
>
> Please don't send plaintext documents in inscrutable MIME encoding!
Sorry :( , I will be more careful next time. And for now I
will append my (revised) proposal at the bottom of the message.
> > Proposed model of the problem:
> >
> > KCI = Kernel Canonical Identifier
> > currently mayor and minor device number pairs
> > USN = UserSpace Name
> > currently the name of the device file
> >
> > As I see it, DEVFS changes the KCI from a pair of numbers into a path
> > like string.
> > And at least without devfsd, it makes user programs use KCIs
> > directly, which could be seen as currently having to use device
> > major and minor numbers directly. Stablishing policy in the kernel.
>
> You're *supposed* to run devfsd, so you can establish your own policy
> (as well as intelligent device management). But it's important for the
> kernel to provide a default policy which all application writers can
> depend on.
>
> The rest of your proposals relate to allowing a distribution to put in
> their own policy. We can already do that with devfsd, so your
> proposals aren't buying anything (other than replacing devfs with a
> (less flexible) mechanism which doesn't have the "devfs" badge).
I personally like devfs the way it is, I am not trying to
replace it or to make it more powerful or to add new features, I am
just proposing to change it slightly to make it more desirable, or
maybe more bearable to those who currently don't like it.
ranty
PS: sorry for coming back so late, but I was away from my computer.
-------------------------------------------------
Manuel Estrada
Ranty@atdot.org
-------------------------------------------------
Proposed model of the problem:
KCI = Kernel Canonical Identifier
currently mayor and minor device number pairs
USN = UserSpace Name
currently the name of the device file
As it could be seen, DEVFS changes the KCI from a pair of numbers into a path
like string.
And at least without devfsd, it makes user programs use KCIs directly,
which could be seen as currently having to use device major and minor numbers
directly. Establishing policy in the kernel.
Possible solutions:
1) Similar to the current schema both old KCIs (device numbers) and new
KCIs (strings) could be stored in the inode and still let the name of
the device be the USN. And in a DEVFS capable kernel they would
behave like a "symlink into DEVFS wherever it may be mounted or not".
This doesn`t make DEVFS any more optional than it is now as some
want but it does make it work like the traditional way which may be
good enough. And hopefully it could be accomplished without breaking
compatibility with non DEVFS aware kernels.
2) This one I believe is too much, but I will leave it here just for the
record.
Is a little bit more complicated, I propose two more concepts:
USDN=UserSpace Default Name
compile time defined, easily modifiable in a single file
and distro dependent. And by default would be the same
as the KCI.
USVN=UserSpace deVfsd Name
resolved at runtime asking devfsd if it is available and
wants to resolve it.
In this one, the mapping between KCIs and USNs would work in the
following way:
USN = "is USVN available" ? USVN : USDN;
This would allow for easy changing kernel imposed policy without
devfsd while maintaining all devfs flexibility.
Also to improve flexibility, whatever data structure maps KCIs into
USDNs could be loaded as a module or even modifiable at runtime with
some ioctl or something.
Also with some mount time flag KCIs would be used directly for easier
inter-distro compatibility, to be mounted in something like /devfs/
then:
/dev/ would be distro dependent
/devfs/ would be distro independent (kernel dependent)
3) There could be some way to make some files appear unther /proc
automagicly then /devfs is not enabled making /devfs more optinal
without much work, or at least without much duplicated work.
Lets say the /devfs device registering functions stay there even if
/devfs is not enabled, but what the do under this circunstance is
simply make some file in /proc, this could be asked for by the code
with some flag.
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:15 EST