> If i remember correctly both Linux and it predecessor (minix) use hardware
> scrolling.
> You might want to add that functionality to either the console or the vga
> driver.
I don't know how to do this, and it would reduce the generality of
the upper-level console driver to implement it. Someone who knows more
about hardware hackery than I is welcome to implement something like this
in the lower edge, though.
> >put together an IP stack, and I might take a small detour and oblige them
> >with a serial driver (if I can find docs!) to test against Linux SLIP***.
>
> I'm sorry to sound so negative, but the stack is going to take a while to
> reach useable (tcp) level. Don't expect it to be fast either. Usually this
> code uses some tyical C approaches to memory, arrays, structs, unions and
> typecasts that force me to do most of my packet parsing with byte to byte
> copies.
Okay, just let me know if/when a serial driver would come in handy
for testing. As for terrible C approaches to data structures, doesn't
DataInputStream let you pull out varying primitive types? (They probably
won't be in the right byte order, though...)
> On a lighter note, i would like JEPS (as i like to call the stack) to be
> more or less compatible with the way jjos handles its classes
> (NetworkInterfaceDriver is already a superclass of
> jos.platform.driver.Device), do any of you kernel persons have any hints on
> that?
The driver architecture is about to undergo a fairly substantial
change, and probably another one a few months after that, so I wouldn't
get too attatched to your package names. Aside from that, no, not really.
John, you have anything more substantial to add?
> One other thing, if i have to handle multiple interfaces, i can't allow a
> call to any of them to block. The neat way of handling this would be the
> windows WaitForMultipleEvent way ..
> Pass it a list of events and wake me when one arrives. Then i can service
> it and wait upon that event list again.
> Is an event structure like this going to be implemented?
Your driver can listen to any number of event sources, viz:
interrupts.addInterruptListener( 9, this );
interrupts.addInterruptListener( 10, this );
interrupts.addInterruptListener( 11, this );
for three different interrupts, or
driver-tree.interface0.addPacketListener(this);
driver-tree.interface1.addPacketListener(this);
driver-tree.interface2.addPacketListener(this);
and so on. When its init() (or whatever) method exits,
handleInterrupt() or packetReceived() method will be called; if the
PacketEvent is done right, it would include the source object. The
only tricky bit is that the packetReceived() method might be called by
three different threads. It would therefore be wise to synchronize the
method and have it do a minimum of work and wake up its own dedicated
servicing thread(s). Likewise, if you're listening for more than one type
of event, two different functions might be executing 'simultaneously'.
On the other hand, does your stack have to be a soliton/static
class? Why not create stack objects (who share code but not state data),
one to an interface?
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
