On Mon, 10 Jan 2000, Alexander Viro wrote:
>
>
> On Sun, 9 Jan 2000, Oliver Xymoron wrote:
>
> > On Sat, 8 Jan 2000, Alexander Viro wrote:
> >
> > > > Don't forget to include the bdev/cdev bit in devno.]
> > >
> > > No, thanks. Character devices _are_ different; by coincidence we
> > > are using 16bit integers to refer both to block and character devices, but
> > > that's about it.
> >
> > But they're still both "files". What is gained by having any code outside
> > of the functions that are pointed to in the file operations table know
> > there's a difference? I just don't get it. How is this simpler? Why can't
> > a device id (type:major:minor) simply be a way to locate the file
> > operations table for a device?
>
> Because they are _more_ than files. Because their native interface is
> _not_ a file one. Because there is a way to produce a file interface from
> block device one and _that_ is what fs/block_dev.c does. I.e. it's an
> interface converter.
>
> Now, look at the mount(). Or swapon(). Tell me, where is a file? Or inode,
> for that matter (esp. for root mount). See also ioctl() usage in ISOFS.
> Where the hell is a file? See also raw devices - there you _have_ file,
> but the problem is that it's already in use.
You can look at mount as a fancy version of link. We have hard links (any
file), we have soft links (pointers to location), nothing prevents us from
having "mount links".
As for swapon we can make "/proc/memory/swap/" directory with semantics
that when we make "mount link" in it it adds swap.
My own opinion is that sufficiently generic model can always explain
other models in its own terms. However, abstract models aside, one should
look at the nature of what he/she is trying to accomplish to make a
decision.
What is block device ? An array of records. The size of it doesn't
change while in use. The records can be stored an retrieved.
What is character device ? (I'll take an example of serial port)
Communications channel - you can read and write to it, but usually
data read and written is not preserved. Its size depends on the amount
of data available to be read. (or you can say that size is not defined)
What is file ? mixture of both. You can consider it as array of records
and you read and write from it.
Now I think it's obvious that block devices and character devices are
two different beasts. Whatever you do in the end a device driver _will_
have to distinguish them - because it deals with a physical device and
not an abstract concept.
Vladimir Dergachev
>
> They are not files. There is a way to make a file out of a block device,
> and that's fine - that's all users see (almost). But for the kernel they
> _are_ different.
>
> > Plus the i_bdev thing is kindof ugly too - it should be i_private or
> > something like the private_data in struct file. If the inode in question
> > is not a block device, then someone else (named pipes, perhaps?) can use
> > the pointer for their own private storage.
>
> Oh, please. Yes, we can merge that with FIFO pointer. But complaining
> about the struct inode bloat is kinda funny - the first thing to do is
> going for separate allocation of per-fs data.
>
>
> -
> 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/
>
-
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 : Sat Jan 15 2000 - 21:00:19 EST