proposed patch to improve seperation between kernel and userland code

Chris Pressey cpressey at catseye.mine.nu
Sun Mar 14 20:15:00 PST 2004


On Sun, 14 Mar 2004 18:54:58 -0800 (PST)
Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:

> 
> :The attached patch probably deserves some discussion, so I'm posting
> it:here first rather than straight to the submit list.
> :
> :The idea is to enhance the distinction between kernel source code and
> :userland source code.  (This started as sort of an offshoot of
> removing:parameter names from function protoypes in
> userland-accessible headers.)
> 
>      * libdisk should probably still be made part of the build.

OK, but I'm not sure why.  The only consumer of libdisk in the base
system is sysinstall AFAICT, and from what I understand, that's going
away, thanks to Rob.  If there happen to be ports or other 3rd-party
software that use libdisk, well, how about making libdisk itself a port?

>      * I'm on the fence in regards to sys/dir.h.  If it is possible I
>        would prefer that it be left working.

OK.  I just wanted to push the envelope and see how much I could shut
off without breakage - I have no strong feelings on killing sys/dir.h,
so I'll put it back.

>      Generally speaking, the stuff looks pretty good.  I think it is
>      commitable with the above two changes, with the provisio that we
>      may have to revert additional pieces of it if we start getting
>      complaints about ports.

Since it's only a matter of adding a #define or tweaking an #include,
I'd rather patch the ports (except where I might've miscalculated with
which headers truly deserve these kernel-only distinctions of course.)
It's actually 3rd-party software that's not in the ports tree that
worries me more - I don't want DFly to get a reputation for "hard to
build sources on because they do funky things with their headers".
(Obviously I don't think they're funky, I think they're *sane*, but...)

I'll go re-install some ports at random to test for breakage now.

> 						-Matt
> 

Thanks,

-Chris





More information about the Kernel mailing list