Re: Driver API (was Re: Linux GPL and binary module exception clause?)

[Hannu Savolainen]

On Thu, 11 Dec 2003 viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:

> It doesn't work.  Let me give you an example: right now we have a way to get
> from struct inode to struct block device - inode->i_bdev.  You can wrap it
> into helper functions, whatever - it won't live to 2.8.
>
> 	Why?  Because if we want to handle device removal in a sane way, that
> association will have to go.  We will still have a need (and a way) to get
> from opened struct file of block device to its struct block_device.  And _that_
> association will remain stable through the entire life of struct file.  Even
> when the mapping from inode to block device gets changed.
I don't see this as a problem. I'm talking about an ABI for _character_
drivers only. Everybody who needs a "loosely coupled" device driver
will probably want to implement a character driver. If you look at any
operating systems there are very few differences between the character
driver interfaces of them. There have not been any dramatic changes in
this interface since Linux 0.99.x times. Some parameters have changed but
that's almost it.

Block devices, network devices and things like that are tighter coupled
by nature. I don't eventry to claim it's going to be possible to create
an ABI for them. At least I don't see it necessary.

In a charcter driver all you need to know from the inode structure is
basicly just the device (minor) number. It's not hard to implement the
ABI layer so that the minor number can be provided regardless of the
changes made to the kernel behind it.

To the client driver the ABI "wrapper" is a black box. It can't
see what is inside the box. In particular it can't see the kernel behind
it. If something changes in the kernel some changes are needed to the
internals of the box too.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@xxxxxxxxxxxxx)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/