Re: system calls, like uname
This is a useful idea, but the LSB doesn't have the capacity to drive
it's development. We'd probably be glad to work with someone who does have
the time to develop it, and make comments that will help ensure that it can
be easily added to the LSB.
We have a prefereed order of how we adopt things. Using something that exists
is at the top of the list, and having to develop something is at the bottom,
and is only an approach when there is a serious problem with no other
solution. Even this approach ends up being we discuss it, and someone goes off
and works on an implementation that would then elevate it so we could adopt
something that exists.
As to this suggestion in particular, I'd suggest creating a library interface
for providing the kind of information you are after. Details like a new
system call or accessing /proc would then be hidden behind the libraries
interface and becomes just an implementation detail. Wether /proc is text
or binary based is irrelevent to an application which is using the libraries
interfaces. The underlying implementation of /proc or a system call can even
change as the kernel changes, but the library will handle the changes, and
continue to present the same API to the application.
The API should be general enough to allow new features/attributes to be added
without having to change the API.
Ideally, 3 things would happen in parallel:
1) A specification of the API is written. This could be very similar
to a collection of man pages. This needs to be very complete.
2) An implementation of the API is developed to match the
specification.
3) A Test suite is developed based on the written specification. This
can then be run against the implementation.
On Thu, 15 Jul 1999, Robert W. Current wrote:
> Forgive me if I am out of line here, but is there anyone who can speak
> from an inside prespective of both kernel development with an inside
> understanding on the LSB as well that can comment on this? Like, is
> Alan Cox or someone lurking on this list, and could they comment?
>
> Aaron Gaudio wrote:
> >
> > And lo, the chronicles report that Robert W.
> > Current spake thusly unto the masses:
> > >
> > > So, I think I am inclined to disagree. I don't think something like
> > > uname would be in the scope of kernel development.
> >
> > Actually, uname is already in the scope of kernel
> > development: it's a system call- uname(2)
> > The original poster was saying that there should
> > be another system call which returns information
> > about the hardware. I personally think the kernel
> > already has a way to return hardware information:
> > it's called the proc filesystem. But whether you
> > feel this functionality belongs in the kernel or
> > userland is irrelevant here, since if there
> > isn't anything already which does this, I don't
> > think LSB should conjure one up.
> >
> > If you think it belongs in the kernel,
> > it should be discussed on the kernel lists.
> > If you think it belongs as an app then find
> > some developers who agree and are willing to work
> > on it.
> >
> > Either way, LSB shouldn't be concerned with it
> > until there is something there to be concerned with.
> >
>
> --
> "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
>
>
> --
> To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
>
Stuart
Stuart R. Anderson anderson@metrolink.com
Metro Link Incorporated South Carolina Office
4711 North Powerline Road 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.938.0283 voice: 803.951.3630
fax: 954.938.1982 SkyTel: 800.405.3401
http://www.metrolink.com/
Reply to: