David Given writes:
>
> [...]
> >We create a meta driver called something like the user device driver which
> >has a whole load of generically named devices in /dev/udd0 -- /dev/udd<n>.
> >
> [...]
> > while ((y = ioctl(x, UDD_WAIT_REQUEST, &bar)) == 0) {
> > process_device_request(&bar);
> > }
> >
> >Device requests such as open, close, reads, writes, ioctls etc are
> >all dealt with by calling the kernel with other ioctls which contain
> >information about the call. If for example it recieved a read() request
> >the reply would look something like this.
> [...]
> >Is anyone interested in this type of scheme?
>
> I seem to recall that sometime last year, on another iteration of the same
> discussion, someone suggested something similar and various people decided
> that it would be too slow; before a device driver request can be completed,
> the scheduler has to restart the process to handle it. It may have been Alan
> Cox who said this. Whoever it was brought up Minix, which uses something
> similar to talk to its devices.
>
> How much overhead is there in an ioctl?
>
Not very much. I am not advocating using this technique for all device
drivers, but it would alow more obscure stuff that we would never fit into
the kernel to work, and might be a good way to open the door to sensible
networking.
The scheduler could have extra rules added so that we can ensure the right
context switch when this event occurs.
I am very eneasy about going down any road that involves the use of far
pointers. The compiler is currently pretty stable, and the system is
getting there which is quite remarkable given that we have no real memory
protection. If we start adding new features to the compiler or shift over
to another one, or start widely using far pointers, I am worried that
we lose the stability we have worked for so long to achieve.
In any case we lose nothing by building a test implementation.
I intend to have a go at this and intend to have the bulk of the code
written by the end of next week.
Al
