lkml.org 
[lkml]   [1997]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: useful LKM?
On Thu, 2 Oct 1997, Darren Reed wrote:

> In some mail I received from Jacques Gelinas, sie wrote
> [...]
> > By combining solution 2 and 3, we would be in a better shape, without
> > inventing new APIs.
>
> Option 1 you presented is the sort of thing you'd find in Solaris or
> Windows NT - put there to make life easier for new developers and
> future compatibility. The point here is, given its presence, you can
> rewrite the kernel completely but not have to rewrite an LKM that interacts
> with it (although I wouldn't count on it). There are other advantages too,
> but they all cost something.
>
> I think if you do combine 2 & 3, you do end up with a new API.

Yes and no. This API spec already exist in the developpers mind. For
example, a filesystem module should not play directly with some features
of the VFS but instead use specific services to achieve that. This
__MODULE__ thing allows the VFS developper to say that quite clearly.
Think of it as the private keyword of C++.

> Has anyone actually quantified the difference in memory usage that
> results in structures having different sizes due to compile-tiome
> options ? And then observed how big that change is in reality to a
> running system ?

This is quite often not that much. There is already one part of the kernel
which is module aware in that regard. It is the the "struct inode" in
/usr/include/linux/fs.h. Even if for example, the minix fs is not compiled
in the kernel, the union always include the field

struct minix_inode_info minix_i;

This allows one to load the minix module later and expect the "struct
inode" to be compliant. So "struct inode" is always full side and this
since about 2-3 years and life goes on (well I think ext2 is the biggest
member of the union anyway, so I am lying).

Ultimatly, this optimisation could even be a compile time option

[ ] Squeeze as much memory as need

struct foo {
.
#if define(KERNEL_OPTION) || !defined(KERNEL_SQUEEZE)
struct sub_foo *pt;
#endif
.
};

This would allows tuning for those who want to play with that. And for
sure, this strategy is a case by case one. Developper may decide if a
field is worth letting there to get better module compatibility or not.


> How badly is a better system needed and does anyone want to pay the price ?

The price is very low here. We can start incrementally to limit the
visibility of few header part. The nice thing is that it does not imply
recoding anything. We hide few parts and recompile the module which needs
it. If it still compiles, then it may remain hidden :-)

People are not ready to create some layer which isolate the module from
the internal of the OS and this for various reason. One poster on this
list reported that NT interrupt latency was up to 4 time longer than linux
(measured with a scope). Obviously, we are quite proud of the level of
performance of linux and don't want to fall slow.

So we want modules and drivers which fits tightly with the OS, yet we
would like to get the versionning to work a little more that it is working
now.


--------------------------------------------------------
Jacques Gelinas (jacques@solucorp.qc.ca)
Linuxconf: The ultimate administration system for Linux.
see http://www.solucorp.qc.ca/linuxconf
new developments: mail to fax gateway, disk quota management, RPM for redhat



\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.084 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site