Trimming Device Drivers

Trimming Device Drivers

Post by dkagl » Sat, 19 Nov 1994 06:57:18



The location and configuration of device drivers is a bit different in Linux
then the other UNIX's. I've located the config files ( .c ) along with a
Makefile for the drivers.  By removing unneeded config files ( .c ) from the  
Makefile and the directory, will this cause problems. Otherwise is there a
'master' file with all of the drivers in it that the kernel utilizes when
it rebuilds. ( ie. /etc/conf/cf.d ).

Thanks
Don

--------------------------------------------------------------------
Our thoughts strayed constantly and without boundary
The ringing of the division bell had begun.
--------------------------------------------------------------------

 
 
 

Trimming Device Drivers

Post by Mike Cast » Sat, 19 Nov 1994 15:39:51




>The location and configuration of device drivers is a bit different in Linux
>then the other UNIX's. I've located the config files ( .c ) along with a
>Makefile for the drivers.  By removing unneeded config files ( .c ) from the  
>Makefile and the directory, will this cause problems. Otherwise is there a

Most likely, it will.

Quote:>'master' file with all of the drivers in it that the kernel utilizes when
>it rebuilds. ( ie. /etc/conf/cf.d ).

type "make config" in the top level of the source tree (typically
/usr/src/linux) and it will let you configure out the drivers
you don't want.
--
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly


    We are all of us living in the shadow of Manhattan.  -- Watchmen

 
 
 

1. Device driver calling another device driver.

Hi.

I am having a problem writing a "meta-driver", ie one that is sandwiched
between the kernel and a real device driver. The platform I am using
consists of a Sun IPC, running SunOS 4.1.1.

My problem is that in attempting to use the OPEN(2V) system call from within
the "xxopen" routine of my metadriver (to open another device-driver (which
then opens the device)); OPEN(2V) "fails".

It appears that calling OPEN(2V) from within the kernel requires a different
calling sequence and argument list. Viz-a-viz: instead of a file descriptor
being returned by OPEN(2V), it seems a pointer is returned (which itself is
a pointer to something else).

Is this true? Is the OPEN(2V) syscall different for a process executing in
user address space, compared to the OPEN call executed by a process running
in kernel mode/address space?

If this is true for OPEN, what about CLOSE, READ, WRITE, etc? Unfortunately,
I don't have (easy) access to any Unix (source) code, to verify this.

Thanks in advance for help/advice.

2. Can't install xisp-2.2p2-1.i386.rpm

3. Device driver question (generic device driver)

4. gnome & gnucash

5. PCI device vs SCSI device driver

6. Future of Java question....

7. Device driver for a device

8. /dev/modem -> to hell !!

9. Device driver devices.pci.scsi missing

10. New device device driver development tool for Solaris.

11. one device driver and 2 devices for it, impossible with linux ?

12. My first device driver => "No such device" :(

13. New device device driver development tool for Solaris.