Skip site navigation (1)Skip section navigation (2)
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>