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. Message-ID: <Pine.BSF.3.95.980614123330.6386B-100000@current1.whistle.com> In-Reply-To: <199806141927.VAA07020@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
It fails here on a new partition (maybe it's because I'm a bit ahead in code). the problem is that newfs does: open device Writeonly. open device Readonly (different fd) write to device (write fd) (failed) do you newfs the block or Char device? do you specify the whole path? when did you last try it? Unfortunatly the way the slice code runs right now (at least here) the 2nd open set the device back to readonly. This is what I fixed. 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 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) On Sun, 14 Jun 1998, S?ren Schmidt wrote: > In reply to Julian Elischer who wrote: > > julian 1998/06/14 12:00:14 PDT > > > > Modified files: > > sys/dev/slice slice_base.c > > Log: > > Horrible hack to allow newfs to work again in SLICE kernels. > > Real fix in the making but requires editing 60+ files. (every damn driver) > > Why ?? newfs has worked fine for me ?? > Oh and it now works on >8G drives, I run DEVFS/SLICE on my main box > here with 11.5G EIDE disk, no probs... > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end? > .. > 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.980614123330.6386B-100000>