Ramon van Handel wrote:
>
> Once again, it looks great !!! Nice base for further coding.
> Only, C++ comments are so ugly :) (never mind, I'm a bit
> weird ;)).
I like C++ comments because they're less intrusive and you don't
have to worry about where the end of the comment is. I used
to hate them, then I converted.
> I would have tried to debug the interrupt problem tonight,
> but it all went wrong. The problem is that my base development
> PC (this one) is an SMP box, and your kernel module made it go
> all wrong with the IPIs, because you don't forward those
> to the kernel ! eek, aargh, etc. I'll need to compile a
> non-SMP kernel one of these days, but that'll probably have
> to wait until the weekend.
>
> I did spot one bug fairly rapidly:
> In host-linux.c, line 240, I'm quite sure that should be
>
> soft_int_vector = SLAVE_PIC_BASE_VECTOR + monitor_info.vector - 8;
>
> Without the -8, you're calling wrong interrupts !!!
Thanks for spotting this. You and Ulrich both spotted the
same problem.
I was thinking about how this interrupt redirection might screw
up SMP Linux boxes. Maybe we need to conditionally compile in a
different routine to redirect the HW interrupt in SMP mode.
Or maybe you can add the additional interrupt as Ulrich pointed
out. I'm not certain.
> Another thing, it may be that linux expects interrupts to be
> on when an interrupt occurs --- I don't know whether it really
> matters, but I wouldn't hestitate to make such an assumption
> in MY OS code, if I needed to :). So it may be nice to
> sti() BEFORE forwarding the interrupt to the host kernel.
You should be able to stick the sti instruction in the
soft_int() macro, just before the int #n call. Interrupts
won't be taken until the following instruction completes,
and the int #n instruction turns them back off anyways.
Go for it, give it a try. Should be OK. I had that in
there at some point, then deleted it while debugging etc.
Don't think it hurt any.
> Do you mind if I go through your code and clean it up a bit ?
> By that I mean putting #defines in header files, and adding
> large amounts of documentation where your code is a bit cryptic.
> Better have documentation right from the start, and hey,
> there's no better way to learn how a piece of code works than
> trying to document it (except, of course, writing it yourself :))
Hey go nuts. You are head man in charge of cleaning up
and commenting the code. If you want any help with comments,
let me know.
We should probably use standard ioctl() command conventions
and stuff like that. Go to town on any of it you want to.
I'm trying to keep things so that this compiles on a decent
range of Linux kernels. I happen to have 2.0.36 and 2.2.5,
so that's what I tested it on anyways. Any improvements
you can offer are welcome. There was a change in segmentation
between those kernels, so it kept me honest. 2.0.36 uses
kernel segs with base of 0xc0000000, and 2.2.5 with base
of 0x00000000. The GDT and IDT are kept in strict linear
address space without the base offset of the seg regs,
so you have to be careful when accessing them, I found. :^)
Other things on the todo list are:
Making sure multiple user processes can't access the
kernel module at one time (for now), except a mechanism
to reset the module driver use count in case we mess up
and want to rmmod it. I have the user/resetmod.c program
for this, but there may be a better way.
I don't user the minor number yet, but we could split the
FreeMWare major number into various channels, which could
be fopen()'d. Maybe one for the memory space, etc.
Once we solidify on the major/minor number issues, we should
file for an official FreeMWare major number. Somewhere in
my kernel book it gives the place to do that.
> Also, I don't want to whine too much about this but I think
> that we need to make some kind of arrangement about coding style
> (nothing fixed, just general guidelines --- that's always useful
> if multiple people need to work on the same piece of code.) On
> my wishlist are bigger tabstops than Kevin uses, and to get rid
> of C++-style comments (but that's probably not going to be ;))
I'm up for some suggested guidelines. It might make things go
more smoothly. Keep in mind though this is code by anarchy, so
we shouldn't push any hard rules. The incentive to not having
any hard rules is that you have more incentive to write more code,
because then it's exactly to your liking. :^)
-Kevin
