Re: system calls, like uname
All applications are "outside" of the kernel, that's where the LSB comes
in.
cat, du, df, uname, etc... all of these are not part of the Linux
kernel. They are not included in the kernel source.
Technically, you can release a Linux distribution without many "common"
applictions, or with partially functioning ones, or incompatable ones.
And some distributions do (albiet, mostly just the "single disk Linux"
distributions, so, they do have a reason, but, they may be "Linux" but
probably are not going to be "LSB Compliant").
Kernel developers, AFAIK, don't deal with -any- applications. If
anything, it's applications like cat, df, uname, etc., that slow down
kernel development, because the kernel is expected to still be a
platform to compile and use these apps. There might be a case there
where it would be "an additional burden to develop the kernel with
another application to think about being compatiable with", but as for
the development of Linux as a whole, I think the benifits in this case
would clearly outweigh this.
If you want to talk about kernel level to userland application
development, a scheme like *BSD's development where "make world"
rebuilds both at the same time to keep compatibility is very
benificial. But, that's far outside the focus of my suggestion.
Basic applications were, IMHO, the focus of the LSB, and some will have
to be tweaked and moved into FHS compliance and conform to "industrial
standards" and there should be an effort to keep the "base" as small as
possable, and let the distributions add thier specifics on top of it.
But, I am talking about an app that would be approximately 48k, not
something that's going to suck up 1M or 2M...
So, I think I am inclined to disagree. I don't think something like
uname would be in the scope of kernel development.
Aaron Gaudio wrote:
>
> I don't think this is in the scope of the LSB until someone
> does it and it beomes accepted usage.
> AFAIK, the LSB is not the business of adding new and untested
> features to software (including the kernel). The first step for
> something like this is to get the kernel developers to agree to it;
> perhaps you should try the kernel-devel list.
>
> >
> > -----Original Message-----
> > On Behalf Of Robert W. Current
> >
> > I suggest a general system call be implemented to obtain information
> > about hardware.
--
"Robert W. Current" <rob@freshmeat.net> - email
http://chem20.chem.und.nodak.edu - work stuff
http://www.current.nu - personal web site
http://freshmeat.net - editorial coordinator
"Hey mister, turn it on, turn it up, and turn me loose." - Dwight Yoakam
Reply to: