From owner-freebsd-current Wed Jun 17 11:53:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11811 for freebsd-current-outgoing; Wed, 17 Jun 1998 11:53:47 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from papillon.lemis.com (rider.dunham.org [207.170.123.194]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11799 for ; Wed, 17 Jun 1998 11:53:43 -0700 (PDT) (envelope-from grog@lemis.com) Received: (grog@localhost) by papillon.lemis.com (8.8.8/8.6.12) id NAA00776; Wed, 17 Jun 1998 13:03:38 -0500 (CDT) Message-ID: <19980617130336.39533@papillon.lemis.com> Date: Wed, 17 Jun 1998 13:03:36 -0500 From: Greg Lehey To: Julian Elischer , current@FreeBSD.ORG Subject: Re: RFC: Change to the device interface References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Julian Elischer on Sun, Jun 14, 1998 at 01:13:37PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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