On Wed, 30 Jul 1997, Mary Rivett wrote:

[upgrading drivers]

> The only change that I thought was needed in the driver source files was
> to split the cfdriver struct into cfattach and cfdriver. The lines that
> were added in 1.1 to sys/sys/conf.h, sys/arch/i386/i386/conf.c and
> sys/arch/i386/conf/files.i386 were brought forward unchanged. The same 
> major numbers were used as in 1.1. In sys/dev/isa/files/isa, I noticed the
> new attach directive, so the file was modified as follows:
> 
> from (1.1)
>    # SAMS-II triaxial acceleration sensor head
>    device  tsh at isa: isadma 
>    file    dev/isa/tsh.c                  tsh-needs-flag
>    # SAMS-II analog i/o board (RTD-DM5416)
>    device  dm at isa
>    file    dev/isa/dm.c                  dm-needs-flag
> 
> to (1.2.1)
>    # SAMS-II triaxial acceleration sensor head
>    device  tsh: isadma
>    attach  tsh at isa
>    file    dev/isa/tsh.c                 tsh-needs-flag
>    # SAMS-II analog i/o board (RTD-DM5416)
>    device  dm
>    attach  dm at isa
>    file    dev/isa/dm.c                  dm-needs-flag
> 
> Everything configs and builds ok; ioconf.c looks right; mknods were done. 
> There is only one dm device, but 2 tsh devices with minor numbers 0 & 1.
> All 3 device special files are present in /dev.

There are some new major numbers in 1.2 which weren't in 1.1. So it could
be that you need to change the major number. I know you checked it when
you brought forward the patches, but.... Hmm.

I don't know, so I'm guessing, in the hope that I stunble onto the answer.
:-)

> Upon rebooting, the probes for both device types seem to be working, as  
> the kernel reports dm0, tsh0 and tsh1 found. The attaches both seem ok too. 
> 
> The problem occurs when I try to run a test program that opens each device 
> and reads from it. The dm device works fine. The tsh devices fail the open()
> with ENOENT (open '/dev/tsh{0,1}' failed, No such file or directory). It
> never even makes it to the device driver open routine. Why doesn't the
> kernel's open() understand which device's open() I want to use? Why would
> the kernel's open() work ok for the dm device, when the same steps were
> taken to configure the tsh devices? Did something change in open()? With
> handling minor numbers? With device attachment? 

Is the test program sampling from the right device? I mean the one looking
at dm0 spews data which look like they'fr from dm0?

Everything else should be fine.

> I'm out of ideas, so any help would be _greatly_ appreciated. BTW, this is
> my first experience writing Unix device drivers, so I've been kinda flying
> by the seat of my pants. Hopefully it won't turn out that I did something
> really dumb - :)  

Well, I've always found the dumb things were easier to fix. :-)

Good luck!

Bill