Jochen Kuepper wrote:
[ putting stuff into linux-source tree ]
> Well, I am not sure I am entirely happy about that.
[ kernel-patch include schedulers and other stuff ]
> Well, actually the patch should be as small as possible. And fifos,
> schedulers aren't part of that base-package in your definition :-O
At least, it would be fine to have the patch as small as possible,
so that it could make it faster into the standard Kernel,
but from what i have heard and read, Linus will never accept
a basic rt-interrupt-handling-layer like Victor introduced it and
Paolo simplified to RTHAL (this is IMHO a good descriptive
abreviation for what it is: simply a "real time hardware abstraction
layer")
So, at least, we can fit the kernel to our needs.
Also, the real patch to the kernel-sources would be
a small as usual - the additional only would
grow the patch-file a little bit - and as you
prefer reading patch-files, you can also observer
what's going on with the other files. The problem
with copyto is that you have to rely on the
"changes"-files (or doing a diff to the former
version after installing the new one).
> It doesn't actually matter wether it is called patch or copyto.
> I personally prefer the "diff -u" output because to me its simple to read.
> But then I don't see any other disadvantage of the copyto besides it not
> being common usage.
See above: my experiance is that patches are simpler to handle.
> > We could have a structure like this:
> >
> > /usr/src/linux/Documentation/rt/
> > /usr/src/linux/include/linux/rt/
> > /usr/src/linux/arch/i386/rt/
> > /usr/src/linux/arch/ppc/rt
> > /usr/src/linux/arch/m68knommu/rt/
> > /usr/src/linux/rt/schedulers/
> > /usr/src/linux/rt/fifos/
> > /usr/src/linux/rt/semaphores/
>
> That would be a big change to standard linux ! And we agreed to keep the
> Linux kernel changes as small as possible, didn't we ?
The changes to the already _existing_ kernel-source files should
be a small as possible - adding whole directories doesn't violate
this basic idea!
> I would suggest to keep as much as possible outside /usr/src/linux !
agreed: examples and detailed documentation :-)
But i.e. the rtl-Scheduler and rtl-Fifos are similar
to the kernel-scheduler and the ipc-mechanisms.
So why is having a
/usr/src/linux/realtime/scheduler/rtl_sched.c
in parallel with the existing
/usr/src/linux/kernel/sched.c
a bad idea?
Ok, i see the point: it would be simple impossible
to add other RTOSes, or what should we do
if RTL and RTAI will never fit together?
Then i suggest inventing the following structure:
/usr/src/linux/realtime/rtl/scheduler/
/usr/src/linux/realtime/rtai/scheduler/
/usr/src/linux/realtime/rtems/scheduler/
/usr/src/linux/realtime/ecos/scheduler/
/usr/src/linux/realtime/wince/scheduler/
And the best thing: when incooperating the
stuff into the standard kernel sources,
you can choose every rt-option or variant
by simple doing a "make menuconfig"
> > "rt" isn't yet occupied in these directories, and may
> > stand for "rt-linux" and "rtai" as well :-)
> > also, it isn't necessary to have a "linux" after "rt"
> > as Jochen suggested it, as, in this case, "linux" is
> > already included in the full path :-)
>
> Yep. But then I have seen way to much FORTRAN code to like that
> two-character variable. Probably call it "realtime" :-!
realy, sounds better :-)
>
> Well, not native, but I would suggest
> "/usr/src/realtime/rt_posix/examples/" (v.i.:-)
agreed.
> > /opt/src/rtaiapps
>
> Agreed, but put it into /usr/src/realtime/rtai/examples.
agreed.
>
> > or whatsoever. Examples and apps for RTLinux V1.x could have their own
> > /opt/src/rtlapps
>
> /usr/src/realtime/rtl/examples
agreed.
>
> > or the native APIs of RTL1.x and RTAI could be unified to only have a
> >
> > /opt/src/rtapps_np
>
> Well, let'sstill put them into each directory, even at the cost of
> possible duplication :-)
hmm ...
> > or similar (RTL1.x shouldn't be forgotton, since many companies
> > prefer linux-2.0 for developing embedded systems due to
> > a slightly smaller memory footprint)
>
> And less bugs :-)
:-)
> It was pointed ut before that there is something like a get_resolution in
> POSIX, IIRC.
I see: i have to do a little more homework :-)
Bernhard
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
