On Sun, 7 May 2000, Alan Cox wrote:
> > That being said, I personally will not move to devfs until I see broad
> > support by the distros. Sorry but I don't have time to dink around with
> > devfsd and get my system up and running smoothly under the new semantics.
>
> Thats one thing that causes the distro folk a lot of concern too - their
> customers dont like change that breaks everything and ISV's really really
> loathe change.
For a user there is a cost/benefit analysis that is done. What benefit am
I getting from this vs. what is the cost in my time, learning curve, etc.
I'm actually pretty adventurous ;-) but for the forseeable future my time
is limited and the old stuff works, so devfs fails the cost/benefit test
for me. For me breaking a few (many?) things in the process isn't
particularly concerning if I have the time to fix them. All part of the
fun (?!?) For many others I'm sure, this would also be a BIG deal. So,
for right now, changing to devfs for many people would fail a cost/benefit
test. This would make userspace drivers via usbdevfs via devfs also fail
the cost/benefit test.
It would seem that there are two possiblities . . reduce the cost and/or
increase the benefit. Things like the visor hotsyncing on demand via
devfs increases the benefit. Creation of a detailed devfs transition
HOWTO might reduce the cost in time/frustration.
In our case, using the rio500 via userspace as opposed to kernel module
has a decent cost/benefit equation with usbdevfs as is. Change that to
using devfs and then the userspace driver's cost/benefit equation seems
much heavier in cost with no obvious change in the benefit side (from the
user perspective).
> > highest priority goal, then usbdevfs should be functional without devfs.
> > By making devfs a requirement of usbdevfs and thereby a requirement for
> > userspace drivers, the setup required to use a userspace driver now
> > increases significantly. Personally, I think usbdevfs ONLY via devfs is
> > going to grind the move to userspace drivers to a screeching halt. For me
> > personally, if this move is made, I'll move back to the rio kernel driver
> > for the time being.
>
> Devfs support is a good goal. But we need the usbdevfs case covered too. Thats
> much easier to work with. That or we support the 'ioctl fix' device hack. That
> would mean the user mode drivers would do
>
> open via usbdevfs
> failed ?
> open /dev/usbraw
> ioctl(pick the end point)
> open /dev/usbraw
> ioctl(pick the 2nd end point)
> go..
>
> That I think is quite acceptable where wholesale upheavel is not
Yeah, I think the goal is the utilization and adoption of userspace
drivers whenever they make sense. To accomplish that goal, the barriers
for use of these drivers should not be raised by requiring
significant system changes on the user end. If we, as the driver
programmers, need to make some changes during the transition to devfs,
such as your 2nd suggestion, c'e la vie. Not that I want to . .
I'm lazy ;-) but c'e la vie. Requiring users to make significant changes
however will most likely result in the usage of the "same ol'kernel
driver" as opposed to userspace drivers.
Keith
> Alan
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
