Date: Fri, 12 Dec 1997 10:59:32 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org Subject: Re: DEVFS: new sample code Message-ID: <Pine.BSF.3.95.971212104644.28515D-100000@current1.whistle.com> In-Reply-To: <199712121837.FAA00920@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Disclaimer: *this of course only applies to what I'm doing of course* It ain't going to get done there it's getting done in a layer just below, and in conjunction with, the disk label layer. The disklabel layer notices the bad144 flag and sticks the bad144 'wedge' below itself. the bad144 has no business being lower than that because it doesn't cover other slices. They may have their own badblock handlers. it CERTAINLY doesn't get to be in the disk driver because THAT only knows how to move blocks of data and how to propogate up error reports. I've CC'd "current" because this is an issue that I'd like others to comment on. On Sat, 13 Dec 1997, Bruce Evans wrote: > >changes: > > * Disklabel probes can actually fail if there is no disklabel. > > * Debug messages at boot make a lot more sense. > > * Accidentally included (old) bad144 code ifdef'd out (I don't yet > > support that and the lowest level driver is definitly not the place to > > do that anyhow). > > Yes it is. dscheck() should clip the transfer at bad sector boundaries > and somehow get called again if there is more to transfer. dscheck is no longer IN this code. dsxxx() functions are not used by this code. That's the whole point. To replace them with a more modular interface. > > Bruce > julian "help, help I'm being repressed" " Come see the violence inherrent in the system" -Monty Python and the Holy Grail-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.971212104644.28515D-100000>