cvs commit: src/sys/i386/include dvcfg.h physio_proc.h src/sys/amd64/include dvcfg.h physio_proc.h src/sys/compat/netbsd dvcfg.h physio_proc.h src/sys/dev/ct bshw_machdep.c ct.c ct_isa.c src/sys/d

John Baldwin jhb at FreeBSD.org
Tue Mar 16 14:00:36 PST 2004


On Tuesday 16 March 2004 03:56 pm, M. Warner Losh wrote:
> In message: <20040316125222.G96418 at root.org>
>
>             Nate Lawson <nate at root.org> writes:
> : On Tue, 16 Mar 2004, M. Warner Losh wrote:
> : > In message: <20040316.224458.21308983.non at ever.sanda.gr.jp>
> : >
> : >             non at ever.sanda.gr.jp writes:
> : > : From: Takahashi Yoshihiro <nyan at jp.FreeBSD.org>
> : > : Date: Tue, 16 Mar 2004 21:14:53 +0900 (JST)
> : > :
> : > : > In article <200403150741.38591.peter at wemm.org>
> : > : >
> : > : > Peter Wemm <peter at wemm.org> writes:
> : > : > > I don't really care where they go, as long as it isn't in the MD
> : > : > > include areas (they are not MD!), and not in sys/.  My favorites
> : > : > > right now are dev/pc98/* or compat/pc98/*.  I would also like
> : > : > > sys/device_port.h to move there too since it is used by the same
> : > : > > group of ct/ncv/nsp/stg drivers.
> : > : >
> : > : > I repeat that they have NO relations with pc98.  So, the above
> : > : > proposals are not acceptable.
> : > :
> : > : I agree with nyan-san. They are not specific to pc98 not for
> : > : compatibility. I think they should be in sys/ or dev/dev/* or
> : > : somewhere MI and not in compat/* .
> : >
> : > dev/pc98 isn't right.  I have pcmcia cards that are supported by the
> : > ncv, nsp and stg drivers running on an i386 box.  dev/sys is fine by
> : > me too if you are looking for a name.
> :
> : Blech, did you see the suggestion for /src/sys/dev/ic/ ?
>
> Yes.  I saw that since I made it.
>
> I like dev/include, but maybe a more fundamental question is that
> these are a portability layer shared between a number of differen
> systems, does that layer have a name?

Does it even need to exist?  dvcfg seems to provide an array of softc's, 
something we tried to kill in new-bus.  physio_proc() doesn't do anything at 
all.  Is there a reason we use these APIs rather than just chucking the 
physio_proc() one and replacing dvcfg() with sane use of device_get_softc() 
and dev->si_drv1 instead?

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the cvs-src mailing list