Re: [patch] jiffies wraparound (follow up to a Linus post)

Trever Adams (highlander@teleteam.net)
Wed, 28 Oct 1998 00:57:20 -0600


> On Tue, 27 Oct 1998, Alan Cox wrote:
> >
> > Your obsession with new syscalls is misguided IMHO Linus. getpagesize()
> > is a library issue. Hell it doesnt matter if glibc implements it by doing
> > maps on each power of 2 boundary and seeing which is the first not to tail.
> >
> > So why do we need a getpagesize() syscall in the first place 8)
>
> We don't. Notice my "on architectures that need it" comment. Which
> definitely means that i386 will never see it.
>
> Linus

Is Linux Linux? Or are we going to pull a Linux is Linux but this and
that syscall are not available on this or that platform so developers
need to know which platform they are on?

I hate seeing crud that is not needed in any project (and yes, I have
done nothing to help write Linux but help Alan nail down a sound code
bug), but if you are going to have a major syscall on several platforms
(I imagine Sparc/UltraSparc isn't the only one), you need to have it on
all.

I have avoided the /proc discussion so far, but here is probably a good
place to state my idea. Leave it alone, come up with a standard human
readable format, make it binary, or just go away. Those that are
suggesting two directories for it are crazy. We would have to have
formatting/generation code for binary AND text... that is just crazy.
Sure it is just a few bytes of code you say... well I prefer not to run
a bloated unstable platform. BTW, to those yelling that formatting
won't change with binary think again. You just don't have to worry
about byte order... the rest of your formatting etc. will be largely the
same except there would likely be no clues that the format changed until
too late.

The idea I liked the best (if /proc has to change) is to make it all
binary and have userspace (tool shipped with the kernel maybe) throw the
text formatted ones. Keeps the kernel small and allows for great
flexibility. It would be fast for C (and like) programs while allowing
a scriptable interface.

Of course coming from a casual participant this all must be taken with a
grain of salt. I think you will find though that the idea of having the
kernel do both binary and text in /proc would have to be thrown out on
basic software engineering practices.

Trever Adams
highlander@teleteam.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/