Home   Info   DevZone   Wiki  
UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ EthernetDrivers ] [ not logged in ] [ Web: Imported ] goto:  options
[ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

EthernetDrivers for JOS

I am developing Ethernet Drivers in Java for NE2000 compatible Ethernet cards. My goal is to finish by 4/2/98. I'm using Windows NT with a special service that let's me talk to the IO directly. I'm planning on making a java native interface that consists of INP and OUP and go from there.

The NE2000 is cheap. It isn't fast, and it isn't great. I will be testing primarily with this chip since it is used on MANY brands of ethernet cards.

One of the biggest hurdles for a system of device drivers is to use Plug-and-play to recognize the presence of devices. NE2000 cards are notorios for freezing the host processor during automatic probing (typically while probing for SCSI devices). For this reason, it is a good idea to probe for NE2000 cards first, and then mark their I/O space off-limits for subsequent probes.

I'll try to work out a general mechanism for using Plug-and-play probing to find & configure devices. Ideally I'd like JOS to keep its hardware list up-to-date automatically, and then when I plug in a new network card, JOS will:

  1. List several reputable sources for drivers.
  2. Tell me what components the drivers want access to (and why).
  3. Ask me if I want to install one in trusted mode or sandboxed.
Users frequently download new drivers over untrusted networks. There isn't any real way to keep an OS's secure without strictly controlling the driver installation process.

Drivers usually have "highly priviledged" access. I'd like for the drivers model to require that drivers explicitly define which components (upper layers or other drivers) they will interface with.

When I install a new device driver, I really want to know if the driver will also be scanning my hard drive and sending the contents to M$oft for 'consumer research'.

Send mail to me if you think this is overkill.

ExoKernel

Doing network drivers in java is questionable for performance, but it does fit well with the goals of an ExoKernel, where the operating system only acts to control sharing of hardware resources, rather than hiding the hardware behind a layer of abstraction. Developing OS improvements is much easier if abstractions exist in application space, rather than in the kernel.

--PehrAnderson

Hmm. I doubt that anyone had plans to support JNI.... Sun has a device driver spec.... (which is not public yet) Ideas?

--ClarkEvans

Well... Using JNI for development till a JOS kernel is available is no bad idea.. Actually it's the only chance to program and test low-level stuff. That doesn't mean that JNI needs to be supported in JOS. We'll need one or the other sort of native interface anyway though, no matter how primitive it will be... -- MarkusPeter



Content of these pages are owned and copyrighted by the poster.
Hosted by: