On Tue, 23 Jun 2009, Christoph Hellwig wrote:
> we guarantee that f_op is never NULL, so you'll need to assign a
> file operations structure that is empty to it to avoid crashed in
> various places.
Yeah, the patch was just a proof of concept thing (and most places
still check f_op != NULL before dereferncing, so..)
> > It would be logical to reuse the open_flag=3 value, but that has
> > historically been used with different semantics so I'm afraid of
> > touching it.
>
> I think the historical semantics are exactly that you can open it
> an issue ioctls + stat / etc on it ut not actually read/write it.
Two differences between open("foo", 3) and open("foo", O_NOACC):
1) open with "3" requires _read_and_write_ permissions on foo, but
does not allow either read or write. Not sure what the logic in
that, but that's the way it has always been.
2) open with "3" calls driver's ->open() with any side effect that
may have. Open with O_NOACC doesn't do that, and hence if we
want to allow ioctls they need a new interface which gets a
"struct path" instead of a "struct file".
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
