> On Sat, 19 Sep 1998, Jordan Mendelson wrote:
> > Curious, wouldn't having UDI drivers running under Linux make them fairly
> > easy to reverse engineer? I mean, the drivers will be calling linux kernel
> > functions through the UDI kernel interface, so if we trace every call we
> > should be able to get a gist of how the driver works.
>
> You'll find out generic stuff, like what I/O ports the driver uses, and how
> much memory it allocates. Beyond that, you won't get a lot of device-specific
> information because the kernel doesn't have that information--if it did, you
> wouldn't need the driver! :-)
>From reading the specs available from www.sco.com/udi, the only parts of a
UDI driver infrastructure that would be the responsibility of the OEM and
not already implemented in the kernel are what's known as the 'basic
drivers' which are the parts that actually prod registers. Most 'class
drivers' (analogous to Linux' SCSI disc/cdrom/generic stuff) would
probably be implemented by Linux developers in the kernel and thus be
GPL'ed.
The only exceptions to this would be 'Self-contained drivers' which
include both the functionality of the basic drivers and of the class
drivers. These would no doubt be very unpleasant to reverse engineer, but
would most likely only be necessary for non-mainstream devices (is a
digital camera a block or a character device?!). I guess companies like
Diamond might look at using the Self-Contained drivers to add value by
replacing bits of the kernel that they reckon they can write better, but I
think most people would frown upon this and either use a native driver, a
basic driver or avoid that device altogether.
At the very least, people, grab book1.ps.Z ! :)
> --Tim Smith
Best Regards,
Alex.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/