Messages in this thread | | | Date | Wed, 28 Oct 1998 00:57:20 -0600 | From | Trever Adams <> | Subject | Re: [patch] jiffies wraparound (follow up to a Linus post) |
| |
> 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/
| |