Re: Request for comments (kdev_t and friends...)
Martin Dalecki (dalecki@cs.net.pl)
Sat, 27 Nov 1999 02:18:50 +0100
Oliver Xymoron wrote:
>
> On Fri, 26 Nov 1999, Linus Torvalds wrote:
>
> > On Fri, 26 Nov 1999, Oliver Xymoron wrote:
> > >
> > > But why would you want that? Block devices look just like char devices. If
> > > you compare all of the (blk|chr) functions in fs/devices.c, they're
> > > identical except for referencing different arrays.
> >
> > But that's BECAUSE they cannot be different right now. Both block devices
> > and character devices are described by the same descriptor "dev_t", which
> > gets translated to the same type "kdev_t" - whether they are block or
> > character devices is irrelevant to those translations, and thus they have
> > to be the same.
> >
> > So of course they look the same.
> >
> > But that's something we want to change. We want to have the pointer to the
> > block request list available immediately, for example. We don't want to do
> > the current lookup stuff that we do on every block IO start (see
> > ll_rw_block.c and wince). We don't want to have a global block statistics
> > array with magic knowledge about how the minor numbers are allocated
> > (again see ll_rw_block.c and wince).
>
> Ok, but the way we handle this with inodes, dentries, et al is to embed
> the specific data (or a pointer to it) in a generic structure. Code that
> knows it's looking at an ext2 inode can treat it differently than code
> that's just doing some generic inode manipulation. I'm not sure what
> specifically you wanted me to wince at in ll_rw_blk, but I don't see any
> reason this paradigm couldn't be used here. Just add void *llrwmagic. Code
> other than ll_rw_blk needn't care whether it's opening/reading/writing/
> registering/getting stats from a block or a char device.
>
> In fact, we should add at least a void *private so that devices can be
> freed of managing their instance data with static arrays indexed off minor
> number.
>
> Ooh, hey, it's already there in struct file. Along with the read-ahead
> stuff, which is more or less in the same category as the ll_rw_blk stuff.
> Even pos isn't really generic. And this is the right place for such stuff,
> because devices, char or block, are just subclasses of an abstract file:
>
> abstract file
> "normal file"
> pipe
> socket
> device
> char
> block
>
Again I would rather preferr to see the char device stuff moving away
from
block device stuff in the direction of networking devices instead of
repeating the old unix mistake... (Anobody, not counting myself,
still out there remembering that tty's where supposed to *fully* handle
network connections in the early UNIX days? :-).
--
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/