Keith Owens wrote:
> On Thu, 06 Jan 2000 16:14:03 +0000,
> >Does anyone have any ideas what would be needed to add kernel module
> >support (or even whether it is a practical idea).
> IMHO modules for uclinux are silly, production embedded systems should
> be static. However modules can be useful for testing and some code
> cannot be included into the kernel for legal reasons, although the
> recent change to the BSD licence might have fixed that problem. Adding
> module support for uclinux is next on my list of modutils updates, once
> I get modutils 2.3.10 out the door.
> Keith Owens, modutils maintainer.
Thanks to Erwin, Bernhard, Donald J and Keith for your replies. I agree
with your points, but let me explain my thinking about why the module
support (or probably insmod support) would be a requirement for the RT
The normal method of using the RT extensions on x86 is that there is a
patch applied to the kernel which makes the sti/cli request from the
linux kernel become arbitrated by the RT extension (okay there's more to
it than that :-). The rest of the base RT functionality is build as
modules, these include the scheduler and fifos (for IPC). For people
wanting to use RT, a kernel module is written referencing the API
functions in the scheduler/fifos modules. When this is all done, the
user insmods all these modules, and bugs aside has an RT application.
It is certainly true that the scheduler and fifos could be built into
the kernel, but it would be difficult to have to keep rebuilding the
kernel while developing an RT app. Also, it is perfectly reasonable to
expect that you may have more than one RT app that you want to run on
demand (let's say you want to run a data aquision program for 15 minutes
quit and then analyse the data). It seems that the ability to insmod
would mean you only have to have loaded what you need, which is fairly
important with a restricted memory footprint.
Anyhow, I'm not trying to argue with anyone, but I think Keith makes the
points well, and kernel module support would certainly make things
easier for development.
Now, more interestingly, lets get onto some technical ideas. You have
to understand that I'm new to uClinux, so I may have some things wrong
(so please feel free to correct me).
Okay, given that we are using a flat memory model, the user/kernel share
a common memory map (?).
Also given that the user processes are built position independent, when
they are run they are effectively loading into kernel address space (as
they are one and the same thing).
As Donald J says, this means that you don't need to do the
remap_page_range, or the insmod address relocation (as it is PIC).
Does this mean that the main thing that needs to be done to provide the
insmod is the management of the kernel symbol table (registering the new
functions and global data ???)
Anyone have any further ideas.
This message resent by the firstname.lastname@example.org list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:33 EST