Even from an "abstract" point of view the unification between char and
block
devices in the classic UNIX paradigm doesn't fit for the "plurality" of
attachable
physical devices we alredy currently have at the market.
At the old days there where basically just: mass storage -- block
devices
and terminals -- character devices.
But currently we have: still mass storage, where block devices are still
a perfect fit
and the whole zoo of all the other gadgets like video camers, mices,
palm pilots and so on,
where the unification (in classic unix) is just comming in between. The
first sight
that this fundamental design (to have either block based access or just
serial access)
wasn't sufficient was the introduction of a first new separate calss of
devices:
namely networking stuff. Therefore it will for the future make perfect
sense as
Linus is proposing it to make the split between classical char devices
and block devices
(read: mass storage) even more explicit in the design of the kernel.
This will surely
pay for itself as time will pass by and the designers came up with even
more
interresting stuff that one will be able to use in conjuonction with a
central
processing unit ;-).
However I still thing that STRING identifyers inside a kernel
are a bad idea and therefore for example the devfs isn't the proper
soultion, it's
just another symptom (read: ad hock solution of no generic value)
of the basic paradigm problems just described in the sentence
above...
> We want to have ONE structure per device, and we want to have a direct
> pointer to that structure that is looked up _once_ on device open and then
> used ever after. And we want to have /proc just walk the list of allocated
> structures when somebody asks for statistics, instead of the current mess.
>
> > Further, major and minor don't make much sense either anymore. Major
> > should indicate a device type, with minor indicating an instance. But now
> > there are multiple devices within a major (misc, mem) and devices that
> > span majors (tty, scsi). So the terms are more or less arbitrary. So most
> > of the kernel outside drivers themselves should treat device handles as
> > opaque.
>
> The major/minor stuff should never be used in a perfect world, except for
> the initial lookup. After that, you would just have "index within this
> controller" or something, and that depends on the actual hardware.
>
> > I'm not sure about this. Imagine kdev_t was a pointer to fops or something
> > similar. The use of this pointer (in the usual way of using fops) would
> > imply that the device was open, which would imply that the device driver
> > was still around. Then dev->close() is put(dev).
>
> Umm.. Look at where "kdev_t" is used. It's embedded in the buffer cache,
> for example. And right now those have longer lifetimes than open/close.
>
> Of course, maybe the right thing is to just not do that. Not allow buffers
> to survive the close of a device. In which case the "put()" can indeed be
> done at close time.
It was exactly the primary intention of my "naive attempt at the kdev_t"
patch to
acutlly show it the *hard way* how deeply missused this thing get's.
Otherwise I would have changed it to a pointer to some kind of struct of
course...
And sometimes there is even the need for somebody who just doesn't tell:
"All things are wonderfull, keep them until the earth stops rotating as
they are".
However in this particular case I will maybe seriously try to provide
some
of the needed solutions as actual code (If time just permitts.)
>
> Linus
-- Marcin Dalecki- 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/