Date: Mon, 3 Jul 2000 19:36:42 +0100 (BST) From: Nick Hibma <n_hibma@calcaphon.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys bus.h bus_private.h src/sys/kern subr_bus.c Message-ID: <Pine.BSF.4.20.0007031848170.21619-100000@localhost> In-Reply-To: <7268.962643466@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
I take offence to this message. The arrogance displayed in the last paragraph is astonishing. Second, I require that the manpage for device_set_softc contains a sentence that indicates that the softc needs only be set in cases where the softc provided by newbus does not give the driver the required flexiblity (*). Nick (*) Arguments: Memory fragmentation early in the boot process, duplication of code, and the chance of softc lying around after the driver has been unloaded because of not deallocating the softc (broken driver). On Mon, 3 Jul 2000, Poul-Henning Kamp wrote: > In message <Pine.BSF.4.20.0007031737460.21297-100000@localhost>, Nick Hibma wri > tes: > > >If someone can come up with a proper solution for the N:1 and 1:N > >relation problem, I guess that that would help the use of newbus in CAM > >as well (eventhough the pathing in CAM would not be solved yet). > > > >Rewriting the softc is just a silly hack however to which a proper > >solution exists. > > I disagree. > > My belief is that all newbus should do is to store a void * of the > drivers chosing. In particular it shall not allocate storage for > a softc. The contents of the softc is entirely the drivers, newbus > has no business inside the softc, consequently it should not allocate > it. > > >From that point of view, my driver does the right thing. > > But best of all: With the function added, newbus can now support > both models. > > This nicely represents the FreeBSD way: "We provide tools, not > politics". > > And on that note, this particular thread is dead from my end. The > other thread on which device semantics we choose for removeable > devices is *far* more interesting. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" 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.4.20.0007031848170.21619-100000>