traditional syscalls with DRIVER_MODULE ????

[Hans Petter Selasky]

Hi,

On Wednesday 25 May 2011 21:02:29 Jim Bryant wrote:
> do start_read/stop_read and start_write/stop_write map directly to the
> userland read(2) and write(2) calls?

No, but they are called from these calls. The idea is that you use the FIFO 
mechanism already present there when moving data, and poll() will be 
automatically handled. Probably that is not suitable for your purpose?

> i had looked at this previously, and am a bit confused on if the above
> is correct.
> 
> even if they are the direct interface to read(2)/write(2), the issue of
> a poll method for select(2) still exists...
> 
> grepping all DRIVER_MODULE usages comes up with only two poll methods:
> 
> powerpc/powermac/pmu.c:        DEVMETHOD(adb_hb_controller_poll,
> pmu_poll),
> powerpc/powermac/cuda.c:       DEVMETHOD(adb_hb_controller_poll,
> cuda_poll),
> 
> and those are unhelpful.
> 

> please excuse me if these are newbie questions, but, i'm still in the
> learning process.

It is OK to ask questions :-)

> 
> i can do this if there is a way to prevent DRIVER_MODULE from creating
> the devfs nodes, and instead do this in a hybrid way using DRIVER_MODULE
> and make_dev(9), which has the exact traditional functionality i want in
> this.  any ideas?

Why can't you create the node when you receive a device_attach event?

> two of the three device nodes this driver will create
> will require read(2)/select(2) interfaces visible to userland, and the
> third driver will require write(2) visible to userland.

> the question is: is there a way to use DRIVER_MODULE, which seems
> necessary for usbdi, yet create the devfs nodes using make_dev/cdevsw?
> i would prefer to not have DRIVER_MODULE create the device nodes.

DRIVER_MODULE() only will create devices if you have a load function which 
does so. It is only called once!

--HPS