From: Paul I. <pa...@ac...> - 2004-03-13 13:38:49
|
Hi Pavel, That should be ok. For the long term, it sounds reasonable to do it this way if kernel developers agree this usage of sysfs filesystem. I just remembered one discution from last weeks, that files in sysfs have to accept only one value, and output only one value (or something like this). I don't know if I got it right, but if this is the case, we should either move this tree in /proc/acpi/somewhere, or create some other files under each method like {parm1,parm2,parmN,result1,result2,resultN} depending of what that particular method takes as arguments and values it return. Some locking mecanism should be used to be sure that only one program is unsing it a a time. Anyway, this will take time to implement it, but it may have a future. What I am looking for right now, is to have a VERY SMALL module template of an acpi driver for accessing a method with some parameters, and for installing a notify handler on an object in order to receive some events in acpid when that object receives a notify. And it should operate with full path ACPI objects. I don't even want it to be included in main kernel, it can live at acpi site, like the patch for putting your own DSDT table in kernel. I am willing to develop one, but I need a small template because I don't know much about acpi in kernel, and I don't really have a lot of free time to learn it. But if a template would exist, it would be much easyer for me to just modify it to suit my needs. On Fri, 2004-03-12 at 21:59, Pavel Machek wrote: > Hi! > > > > But ioctls are even worse. Why not simply > > > open METHOD > > > write PARAMETERS > > > read RESULTS > > > close > > > > > > > Because I'm too stupid to thing of your solution, I guess. > > Well, instead of doing ioctls on special file, you can simply do > write syscall (telling driver parameters for the method) then read > syscall on same filedescriptor. That is not racy, and it is > less hacky then ioctl() > Pavel |