Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, 17 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, 17 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Fri, 18 May 2001, Brian Somers wrote: On Thu, 17 May 2001, Warner Losh wrote: I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions I agree too :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
John/peter, could you repo-copy src/sys/dev/digi/digiio.h to src/sys/sys/digiio.h ? Ta. On Fri, 18 May 2001, Brian Somers wrote: On Thu, 17 May 2001, Warner Losh wrote: I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions I agree too :-). Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, May 17, 2001 at 07:52:51PM +0300, Ruslan Ermilov wrote:
[...]
There are 59 Makefiles that have -I${.CURDIR}/(../)+sys in them.
All these are bogus. We should get rid of all of them (-I's).
So far, I have found sbin/mount_* use headers from /sys/miscfs/
that are not installed into /usr/include, but should be. Where
should these be installed? /usr/include/fs/fs_from_miscfs or
should we preserve the /usr/include/miscfs/ layout like in
/sys/miscfs? Modern fs'es install their headers into include/fs
and old ones in include/fs.
I have removed the -I${.CURDIR}/.../sys from the half of Makefiles
that do not actually need it. Here is the rest of Makefiles that
have the -I${.CURDIR}/.../sys in them, and it's currently required
because they use headers from /sys that do not get installed into
/usr/include (but should):
sbin/atm/atm/Makefile
sbin/atm/fore_dnld/Makefile
sbin/atm/ilmid/Makefile
sbin/mount_null/Makefile
sbin/mount_portal/Makefile
sbin/mount_umap/Makefile
sbin/mount_union/Makefile
sbin/vinum/Makefile
usr.sbin/acpi/Makefile.inc very interesting example!
usr.sbin/ancontrol/Makefile
usr.sbin/dpt/dpt_ctlinfo/Makefile
usr.sbin/dpt/dpt_ctls/Makefile
usr.sbin/dpt/dpt_dm/Makefile
usr.sbin/dpt/dpt_led/Makefile these even don't compile!!!
usr.sbin/dpt/dpt_sig/Makefile
usr.sbin/dpt/dpt_softc/Makefile
usr.sbin/dpt/dpt_sysinfo/Makefile
usr.sbin/mlxcontrol/Makefile
usr.sbin/pciconf/Makefile
usr.sbin/pnpinfo/Makefile
usr.sbin/pstat/Makefile
usr.sbin/raycontrol/Makefile
usr.sbin/setkey/Makefile
usr.sbin/sicontrol/Makefile
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Fri, May 18, 2001 at 05:11:11PM +0300, Ruslan Ermilov wrote:
On Thu, May 17, 2001 at 07:52:51PM +0300, Ruslan Ermilov wrote:
[...]
There are 59 Makefiles that have -I${.CURDIR}/(../)+sys in them.
All these are bogus. We should get rid of all of them (-I's).
So far, I have found sbin/mount_* use headers from /sys/miscfs/
that are not installed into /usr/include, but should be. Where
should these be installed? /usr/include/fs/fs_from_miscfs or
should we preserve the /usr/include/miscfs/ layout like in
/sys/miscfs? Modern fs'es install their headers into include/fs
and old ones in include/fs.
I have removed the -I${.CURDIR}/.../sys from the half of Makefiles
that do not actually need it. Here is the rest of Makefiles that
have the -I${.CURDIR}/.../sys in them, and it's currently required
because they use headers from /sys that do not get installed into
/usr/include (but should):
[...]
sbin/mount_null/Makefile
sbin/mount_portal/Makefile
sbin/mount_umap/Makefile
sbin/mount_union/Makefile
FS headers should go into /usr/include/fs/fsfs.h, one per
each filesystem.
Boris, could you please move smbfs.h one directory up from the
/usr/include/fs/smbfs/? Also, installing of smbfs_node.h and
smbfs_subr.h seems to be not required as these are used solely
within the kernel.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
Brian Somers wrote: John/peter, could you repo-copy src/sys/dev/digi/digiio.h to src/sys/sys/digiio.h ? Done. Ta. On Fri, 18 May 2001, Brian Somers wrote: On Thu, 17 May 2001, Warner Losh wrote: I quite like the fact that the programming interface sys/fooio.h is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions I agree too :-). Bruce -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. We're not solaris :-). BSD traditionally spells things fooio.h for driver foo. FreeBSD changed the traditional place for devices, so one could argue for both /usr/include/sys/dev/foo/fooio.h or for /usr/include/sys/fooio.h. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
[cc'd to -arch and not to cvs-committers] For anyone that's reading -arch and hasn't seen this on -current, the thread is discussing userland sources that have -I../../sys in their Makefile and then #include sys/dev/blahio.h. I think everyone agrees that these headers should be made public, the question is ``where to put them ?''. Warner wrote: In message [EMAIL PROTECTED] Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). The SHARED variable in src/include/Makefile makes this side of things tricky too - we've got to be careful that we either keep our sources together and maintain a resemblance of the hierarchy in /usr/include or split our sources. When I was working on Solaris I found it better to have the *io.h files in sys (separate from the driver) as it made it very clear that it was a public interface - the driver lived somewhere that just got built into a module and wasn't seen by the outside world. So I think I'd tend to vote (FWIW) for moving digiio.h (and other similar things) out of sys/dev/drivername/ and into sys/sys/. Comments ? -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put include files (was: cvs commit: src Makefile.inc1)
On Thu, May 17, 2001 at 05:37:54PM +0100, Brian Somers wrote:
[cc'd to -arch and not to cvs-committers]
For anyone that's reading -arch and hasn't seen this on -current, the
thread is discussing userland sources that have -I../../sys in their
Makefile and then #include sys/dev/blahio.h.
I think everyone agrees that these headers should be made public, the
question is ``where to put them ?''.
Warner wrote:
In message [EMAIL PROTECTED] Brian
Somers writes:
: Solaris calls it's ioctl files /usr/include/sys/driver_io.h so I'd
: spell digiio.h /usr/include/sys/digi_io.h.
Actually, the more I think about it, the more I like putting it in
/usr/include/sys/fooio.h. We have lots of other files there now. The
down side to this approach is that it breaks up the driver sources
that we've been trying to concentrate into sys/dev/foo/* (or
introduces asymetry such that you can't just toss in a -I/sys and have
the same tree that gets stuck under /usr/include).
The SHARED variable in src/include/Makefile makes this side of things
tricky too - we've got to be careful that we either keep our sources
together and maintain a resemblance of the hierarchy in /usr/include
or split our sources.
When I was working on Solaris I found it better to have the *io.h
files in sys (separate from the driver) as it made it very clear that
it was a public interface - the driver lived somewhere that just got
built into a module and wasn't seen by the outside world.
So I think I'd tend to vote (FWIW) for moving digiio.h (and other
similar things) out of sys/dev/drivername/ and into sys/sys/.
Comments ?
More to that.
There are 59 Makefiles that have -I${.CURDIR}/(../)+sys in them.
All these are bogus. We should get rid of all of them (-I's).
So far, I have found sbin/mount_* use headers from /sys/miscfs/
that are not installed into /usr/include, but should be. Where
should these be installed? /usr/include/fs/fs_from_miscfs or
should we preserve the /usr/include/miscfs/ layout like in
/sys/miscfs? Modern fs'es install their headers into include/fs
and old ones in include/fs.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
