Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Jun 1998 13:03:36 -0500
From:      Greg Lehey <grog@lemis.com>
To:        Julian Elischer <julian@whistle.com>, current@FreeBSD.ORG
Subject:   Re: RFC: Change to the device interface
Message-ID:  <19980617130336.39533@papillon.lemis.com>
In-Reply-To: <Pine.BSF.3.95.980614130923.6386D-100000@current1.whistle.com>; from Julian Elischer on Sun, Jun 14, 1998 at 01:13:37PM -0700
References:  <Pine.BSF.3.95.980614130923.6386D-100000@current1.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 June 1998 at 13:13:37 -0700, Julian Elischer wrote:
>
> It's all due to the fact that a device driver doesn't get told
> about all closes and can't associate IO requests with different open
> requests. To fix this correctly the devsw[] entries should be expanded.
> to have the current close() entrypoint renamed to  be
> "lastclose" and new entrypoint added called changemode() that is notified
> whenever:
>
> 1/ a device is upgraded/downgraded (eg readonly to read-write)
> 2/ a device is closed EVEN IF SOMEONE ELSE HAS IT OPEN
> 3/ possibly whenever an fd is dupe'd or at least when a fork()
>   is done and the filesdescriptor is duplicated.
>
> this could be backwards compatible. if old drivers had a NULL in this
> entrypoint, everything would be as before. NULL is the default for
> additional entries in struct initialisers so no real changes
> would be needed.

Agreed.  I have had a hard time working around the lack of this
feature with vinum.

> A second change would be to make each FILE structure in the kernel
> store a cookie that is returned by the open() call to the driver.
> this would allow the driver to associate an IO request with a particular
> open(). it would be an added arguent to all the devsw[] entrypoints.
>
> Drivers that didn't want it would simply have to change their
> function declarations and could have no real code changes.

I don't have an immediate need for this feature, but I can imagine
that that could change (for example, when vinum includes remote data
replication).  It sounds like a good idea.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980617130336.39533>