Re: [ACPI] Re: [PATCH/RFC] exposing ACPI objects in sysfs

[Pavel Machek]

Hi!

> > If I were you, I'd just replace read and write with ioctl, and leave
> > the rest of design as it was. If we find that someone who bypasses
> > your userspace library, at least we have a way to deal with it. (And
> > "cat a file and kill machine" issue is gone, too).
> 
>    Again, I don't think that solves the problem (and there's no ioctl
> support in sysfs).  The pointer in the command structure is easy to work
> around, nothing uses it and data could easily be stuffed after the
> architected entries.  Switching to an ioctl would not solve the problem
> of passing ACPI data back and forth.  We don't just want to execute

At least we would know we are passing ACPI data from ioctl() argument.

> methods, we want to be able to provide arguments and get data back.
> That data is where I see the biggest 32/64 bit issue.  I'll switch to an
> evaluate on write model, but I'm not sold that an ioctl would solve
> enough problems to be worth it.  Is anyone even open to adding ioctls to
> sysfs bin files?  Thanks,

I do not know what the right solution is. ioctl() is ugly, passing
structures using write() is ugly, too. I think adding ioctl() to sysfs
is less dangerous, because writes can not be translated using compat
layer. Both solutions are ugly and you'll get flamed for both :-(.

Andrew, can you help? We want to call AML methods from userspace, and
defining interface is not fun.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/