> > Well in drivers/net are the network drivers but not the irda and bluetooth > > drivers, > > those are located in different folders in drivers/ so I think misc would be > > the most > > suitable location. > > We could also consider the ./net itself. rfkill is not a driver, it is > a facility.
True, in that case ./net would be good. > > > Does this make sense? > > > > Yes, but what if the user loads both modules or has them both compiled in? > > Shouldn't there be some protection against that, since both handlers should > > not > > be active at the same time. > > Why not? evdev is just a delivery transport for input events to > userspace. Even if user wants the kernel to control state of RF > switches (which I expect most users woudl want) there still could be > applications interested in knowing that used turned off wireless. And > if userspace really wishes to control switch all by itself it can > "claim" it. Right, I forgot about that user_claim thingy. ;) > I guess what you are missing is that input event generated by a device > is pushed through every handler bound to the device so there is no way > for a "wrong" handler to "steals" an event from "right" handler. They > all work simultaneously. > > > > > personally I would prefer enforcing drivers to call > > > > allocate() > > > > register() > > > > unregister() > > > > free() > > > > > > > > Especially with unregister() doing the same steps as free() (put_device) > > > > might be somwhat confusing. But might be just me. ;) > > > > > > > > > > I know but for refcounted objects you can't really tell when they will > > > actually be freed. It depends when their last user drops off. > > > > Then perhaps rfkill_register could call put_device() when it fails, and > > free() > > can be removed entirely. That way it would we prevent some driver > > to call free() anyway. > > > > That would make error handling in ->probe() methods a bit unwieldy I > think - if you are using the standard "goto err_xxx; goto err_yyy;" > technique then you have to conditionally call rfkill_free(). Hovewer > if register simply fails and does not free anything and you call > rfkill_register() last (which you need to do because driver has to be > almost fully functional to be able to serve toggle_radio calls) you > can always call rfkill_free() if something fails. Ok. Well that would mean rfkill would be ready to applied to one of the kernel trees right? :) The first user of rfkill would be rt2x00, which is in wireless-dev as well as -mm. The second user could be the driver from Lennart, but I haven't heard from him quite a while (although he is on the CC list) so I am not sure if his MSI driver can be fixed to use rfkill. His MSI driver is already in the linus' tree. A third user could be bcm43xx but I don't know how far they are with hardware key detection and status reading (to make it work with rfkill), perhaps Larry could give more information about that. Ivo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
