Re: RLIM_INFINITY inconsistency between archs

* Re: RLIM_INFINITY inconsistency between archs
@ 2000-07-31 17:31 Jesse Pollard
  0 siblings, 0 replies; 41+ messages in thread
From: Jesse Pollard @ 2000-07-31 17:31 UTC (permalink / raw)
  To: Kai Henningsen, linux-kernel

---------  Received message begins Here  ---------

> 
> pollard@tomcat.admin.navo.hpc.mil (Jesse Pollard)  wrote on 27.07.00 in <200007271531.KAA89926@tomcat.admin.navo.hpc.mil>:
> 
> > Might I suggest creating a "/lib/include" that works something like
> > the /lib/modules where the kernel name is used to generate the directory
> > for the kernel include files?
> >
> > That way the "uname -r" command could be used to set a symbolic link
> > to point to the correct include files at boot time (or install time).
> 
> Correct for what?
> 
> I think this is silly.
> 
> There are two versions of header files people tend to be interested in:
> 
> a. The ones corresponding to the libc version their linker will link  
> against. This will be good for 99% of the situations.
> 
> b. A special version for some kernel-version-dependant executable. Exact  
> version depends on what they plan to do with that executable - could be  
> most advanced kernel version available, least advanced version available,  
> a specific version whose significance depends on the configuration of a  
> different machine, whatever.
> 
> There is no reason to assume that the currently running kernel version is  
> any more relevant than any of the other arguments for b.
> 
> > This way the kernel that is active would be selecting the correct includes.
> 
> Correct for what?

I said (which got dropped) for things like the RSBAC project, which has
applications that are dependant on the current kernel for proper operation.
The RSBAC project implements multi-level security (among other things) and
supports system calls for manipulating the security labels on the kernel,
and disk files (login, init, ...). The system call list varies depending
on the kernel version, some of the data structures also depends on the
kernel version. The symbolic link would allow a boot time selection of
the correct include files if I need to rebuild/debug them.

When I boot an older/test kernel, the executables used are no longer
valid. Building new executables during test would also invalidate the
older/current ones.

I see using a symbolic link (which I may do on my own) as a way to
preserve system level consistancy, by having different versions of the
executables in my search path/cron job search path.

I can see this also providing advantages for module initialization - well
only the ones that require external hardware initialization. Things like
some wide area net cards, terminal multiplexors...

Some of these require compatablility between module and hardware microcode
for proper functionality. An older kernel will require an older module, and
that older module may require older microcode (not to mention, and older
loader application). Using a version link would simplify the automatic
selection of the proper initialization code.

Now I can do all this on my own, but it might be usefull for more than
just what I see; and others might see pitfalls that I missed.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
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/

^ permalink raw reply	[flat|nested] 41+ messages in thread