Date: Sun, 14 Jun 1998 13:13:37 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: current@FreeBSD.ORG Subject: RFC: Change to the device interface Message-ID: <Pine.BSF.3.95.980614130923.6386D-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
As PHK and others have noted the device interface is broken in a number of ways: Here is a set of suggestions for fixing it (hopefully in a way that will be minimal impact.) The message was originally on another topic.. ---------- Forwarded message ---------- Date: Sun, 14 Jun 1998 12:59:43 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: S?ren Schmidt <sos@FreeBSD.ORG> Cc: current@FreeBSD.ORG, Julian Elischer <julian@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/dev/slice slice_base. [... chop ] 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. 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. This change is more intrusive as it requires edits to all the drivers (but at least they are only mechanical edits). I'm going to prropose a set of patches to do this when I get them done. (may be after Usenix some time) julian 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?Pine.BSF.3.95.980614130923.6386D-100000>