From: Tejun H. <tj...@ke...> - 2008-08-28 18:24:22
|
Miklos Szeredi wrote: > Guessing that CUSE stands for "Character Devices in Userspace"? Yeap, right. > Is there a description of this? It's for sound device emulation, > right? I did it for OSS emulation but it can be used for anything. Hmm... I'm still in the process of pushing out patches, so please wait just a bit. The libfuse changes include simple examples so that should make things a bit clearer. > What is direct-lseek for? It doesn't sound like a feature needed by > char devices. Sound device just sets nonseekable. The direct lseek bit is for API completeness as there are chardevs which have special semantics regarding lseek. Thanks. -- tejun |
From: Greg KH <gr...@kr...> - 2008-08-28 18:22:42
|
On Thu, Aug 28, 2008 at 08:02:44PM +0200, Tejun Heo wrote: > Tejun Heo wrote: > > Greg KH wrote: > >> Why do we need ioctls? For CUSE? In that case, would we need to copy > >> the memory from userspace, into the kernel, and then back out into > >> userspace again? Can't we just have a "pass-through" type fixed ioctl > >> instead? > > > > Can you elaborate a bit? How the fixed ioctl would know how much to > > copy in and out and from where? > > If you're worried about the double copying due to performance reasons, > what we can do is implementing userspace to userspace copying. I just > took easier path of copying twice as u-u copy can't be done using the > existing FUSE mechanics, but frankly, at this point, I think that would > be an premature optimization. No, I'm not worried about the performance, just that this should be simple as we can just pass "arg" to userspace without touching it as it just came from userspace, right? Oh wait, there are process space issues at play here that I'm totally forgetting about, right? thanks, greg k-h |
From: Tejun H. <tj...@ke...> - 2008-08-28 18:26:39
|
Greg KH wrote: > No, I'm not worried about the performance, just that this should be > simple as we can just pass "arg" to userspace without touching it as it > just came from userspace, right? For simple ones, that's how it's gonna be handled. Those copying in and out kicks in when the @arg is pointer or worse data structure which can contain pointers. > Oh wait, there are process space issues at play here that I'm totally > forgetting about, right? :-) Thanks. -- tejun |
From: Miklos S. <mi...@sz...> - 2008-08-28 18:23:52
|
On Thu, 28 Aug 2008, Tejun Heo wrote: > Miklos Szeredi wrote: > >> If you're worried about the double copying due to performance reasons, > >> what we can do is implementing userspace to userspace copying. I just > >> took easier path of copying twice as u-u copy can't be done using the > >> existing FUSE mechanics. > > > > How about not copying anything in the kernel, just passing the virtual > > address to the filesystem? It can get/modify the data of the calling > > task by mapping /proc/pid/mem. Ugly, yes, but ioctls are inherently > > ugly. > > Hmmm... I was trying to stay within similar operation mechanics as other > ops. Directly accessing the caller's memory has performance benefits > but that benefit can also be used by reads and writes. So, if we're > gonna do direct memory access, maybe doing it in more generic way is a > better idea? On the contrary: playing VM games is going to be slow. I think this approach is best suited for generic ioctl support because it simplifies the kernel part. I'd hate to add all that complexity to the kernel if not absolutely necessary. Miklos |
From: H. P. A. <hp...@ke...> - 2008-08-28 18:21:04
|
Tejun Heo wrote: > ioctl support is tricky to implement because only the ioctl > implementation itself knows which memory regions need to be read > and/or written. To support this, fuse client can request retry of > ioctl specifying memory regions to read and write. Deep copying > (nested pointers) can be implemented by retrying multiple times > resolving one depth of dereference at a time. Okay, I'm going to say it... wouldn't it be better to have some kind of data structure description language which the userspace can register with the kernel to linearize the data on a per-ioctl basis (kind of like rpcgen)? -hpa |
From: Tejun H. <tj...@ke...> - 2008-08-28 18:29:12
|
H. Peter Anvin wrote: > Tejun Heo wrote: >> ioctl support is tricky to implement because only the ioctl >> implementation itself knows which memory regions need to be read >> and/or written. To support this, fuse client can request retry of >> ioctl specifying memory regions to read and write. Deep copying >> (nested pointers) can be implemented by retrying multiple times >> resolving one depth of dereference at a time. > > Okay, I'm going to say it... wouldn't it be better to have some kind of > data structure description language which the userspace can register > with the kernel to linearize the data on a per-ioctl basis (kind of like > rpcgen)? Ah.... funky. If this retry thing is too repulsive, I guess the best alternative would be directly accessing caller's memory as Miklos suggested. Thanks. -- tejun |
From: H. P. A. <hp...@ke...> - 2008-08-28 19:08:56
|
Tejun Heo wrote: > > Ah.... funky. If this retry thing is too repulsive, I guess the best > alternative would be directly accessing caller's memory as Miklos suggested. > Be careful -- there are some serious dragons there in the presence of multiple threads. -hpa |
From: Tejun H. <tj...@ke...> - 2008-08-28 18:35:13
|
Miklos Szeredi wrote: >> Hmmm... I was trying to stay within similar operation mechanics as other >> ops. Directly accessing the caller's memory has performance benefits >> but that benefit can also be used by reads and writes. So, if we're >> gonna do direct memory access, maybe doing it in more generic way is a >> better idea? > > On the contrary: playing VM games is going to be slow. I think this > approach is best suited for generic ioctl support because it > simplifies the kernel part. I'd hate to add all that complexity to > the kernel if not absolutely necessary. Well, it's only 240 lines with good amount of comments and iovec copying function. The ioctl itself isn't too complex. I'm a bit skeptical about direct access. It can easily introduce security vulnerabilities as there really is no way to hold a pid. Thanks. -- tejun |
From: Alan C. <al...@lx...> - 2008-08-28 21:06:05
|
> Well, it's only 240 lines with good amount of comments and iovec copying > function. The ioctl itself isn't too complex. I'm a bit skeptical > about direct access. It can easily introduce security vulnerabilities > as there really is no way to hold a pid. Agreed entirely. If and only if there is a future problem with performance someone can introduce a method for the client to pre-describe certain ioctls in terms of number/length/read/write. Alan |
From: Miklos S. <mi...@sz...> - 2008-08-28 19:18:09
|
On Thu, 28 Aug 2008, H. Peter Anvin wrote: > Tejun Heo wrote: > > > > Ah.... funky. If this retry thing is too repulsive, I guess the best > > alternative would be directly accessing caller's memory as Miklos suggested. > > > > Be careful -- there are some serious dragons there in the presence of > multiple threads. OK, it should map /proc/pid/task/tid/mem. Or rather /proc/tid/task/tid/mem, as the pid (tgid) of the caller is not currently passed to the filesystem. Miklos |
From: H. P. A. <hp...@ke...> - 2008-08-28 20:21:23
|
Miklos Szeredi wrote: > On Thu, 28 Aug 2008, H. Peter Anvin wrote: >> Tejun Heo wrote: >>> Ah.... funky. If this retry thing is too repulsive, I guess the best >>> alternative would be directly accessing caller's memory as Miklos suggested. >>> >> Be careful -- there are some serious dragons there in the presence of >> multiple threads. > > OK, it should map /proc/pid/task/tid/mem. Or rather > /proc/tid/task/tid/mem, as the pid (tgid) of the caller is not > currently passed to the filesystem. > Uhm, no. You can still have it change underneath you as long as you have any thread of execution with access to the same memory. This is *hard* to get right, and we screw this up in the kernel with painful regularity. The throught of having user-space processes, which don't have access to the kernel locking primitives and functions like copy_from_user() dealing with this stuff scares me crazy. That is why I'm suggesting using an in-kernel linearizer. -hpa |
From: Miklos S. <mi...@sz...> - 2008-08-28 19:26:02
|
On Thu, 28 Aug 2008, Tejun Heo wrote: > Miklos Szeredi wrote: > >> Hmmm... I was trying to stay within similar operation mechanics as other > >> ops. Directly accessing the caller's memory has performance benefits > >> but that benefit can also be used by reads and writes. So, if we're > >> gonna do direct memory access, maybe doing it in more generic way is a > >> better idea? > > > > On the contrary: playing VM games is going to be slow. I think this > > approach is best suited for generic ioctl support because it > > simplifies the kernel part. I'd hate to add all that complexity to > > the kernel if not absolutely necessary. > > Well, it's only 240 lines with good amount of comments and iovec copying > function. The ioctl itself isn't too complex. I'm a bit skeptical > about direct access. It can easily introduce security vulnerabilities > as there really is no way to hold a pid. I don't understand. No new vulnerabilities are introduced, since it would just use existing infrastructure. Why is it better if the kernel does the copying of memory regions instructed by the userspace filesystem, than if the userspace filesystem does that copying itself? I feel they are totally equivalent, except that the latter needs more complexity in the kernel. Miklos |
From: Tejun H. <tj...@ke...> - 2008-08-28 19:44:05
|
Miklos Szeredi wrote: >> Well, it's only 240 lines with good amount of comments and iovec copying >> function. The ioctl itself isn't too complex. I'm a bit skeptical >> about direct access. It can easily introduce security vulnerabilities >> as there really is no way to hold a pid. > > I don't understand. No new vulnerabilities are introduced, since it > would just use existing infrastructure. > > Why is it better if the kernel does the copying of memory regions > instructed by the userspace filesystem, than if the userspace > filesystem does that copying itself? I feel they are totally > equivalent, except that the latter needs more complexity in the > kernel. I'm no security expert but it feels pretty dangerous to me. First of all, there are cases where the calling process can exit before the userland FUSE is finished with an operation, so it might not be always possible for the FUSE client to tell the PID it got is the correct one. Another thing is that as it currently stands, the kernel side FUSE implementation forms a nice safety net taking responsibility of most security concerns and insulating the mistakes the client may make. Letting userland client to access and possibly modify the caller's memory directly weakens that insulation. Pushing memory access to userland feels a bit too risky to me. There seem to be too many loose components in security sensitive path and I have a nagging feeling that someone will come up with something we can't think of at the moment. Thanks. -- tejun |
From: Miklos S. <mi...@sz...> - 2008-08-28 20:02:16
|
On Thu, 28 Aug 2008, Tejun Heo wrote: > Miklos Szeredi wrote: > >> Well, it's only 240 lines with good amount of comments and iovec copying > >> function. The ioctl itself isn't too complex. I'm a bit skeptical > >> about direct access. It can easily introduce security vulnerabilities > >> as there really is no way to hold a pid. > > > > I don't understand. No new vulnerabilities are introduced, since it > > would just use existing infrastructure. > > > > Why is it better if the kernel does the copying of memory regions > > instructed by the userspace filesystem, than if the userspace > > filesystem does that copying itself? I feel they are totally > > equivalent, except that the latter needs more complexity in the > > kernel. > > I'm no security expert but it feels pretty dangerous to me. First of > all, there are cases where the calling process can exit before the > userland FUSE is finished with an operation, so it might not be always > possible for the FUSE client to tell the PID it got is the correct one. OK, I grant this one. But then it's easy to protect against by getting a ref on the task (or just the task ID, I don't know if that's possible) for the duration of the ioctl. > Another thing is that as it currently stands, the kernel side FUSE > implementation forms a nice safety net taking responsibility of most > security concerns and insulating the mistakes the client may make. > Letting userland client to access and possibly modify the caller's > memory directly weakens that insulation. The same stupid mistakes can be done by giving the wrong instructions to the kernel about what to modify, thus thrashing the calling process. > Pushing memory access to userland feels a bit too risky to me. There > seem to be too many loose components in security sensitive path and I > have a nagging feeling that someone will come up with something we can't > think of at the moment. I don't see the difference. You have to be careful either way, it's not possible to do ioctls safely as the rest of fuse unfortunately. This obviously also means, that it's impossible to run the filesystem as an unprivileged user, as it has to have access to the whole address space of the calling process either way (or ioctls have to be restricted somehow). Miklos |
From: Miklos S. <mi...@sz...> - 2008-08-28 20:56:03
|
On Thu, 28 Aug 2008, H. Peter Anvin wrote: > This is *hard* to get right, and we screw this up in the kernel with > painful regularity. The throught of having user-space processes, which > don't have access to the kernel locking primitives and functions like > copy_from_user() dealing with this stuff scares me crazy. What issues exactly are you thinking of? > That is why I'm suggesting using an in-kernel linearizer. Lots of complexity, ugh... Even Tejun's current scheme is better IMO. Miklos |
From: H. P. A. <hp...@ke...> - 2008-08-28 21:27:27
|
Miklos Szeredi wrote: > On Thu, 28 Aug 2008, H. Peter Anvin wrote: >> This is *hard* to get right, and we screw this up in the kernel with >> painful regularity. The throught of having user-space processes, which >> don't have access to the kernel locking primitives and functions like >> copy_from_user() dealing with this stuff scares me crazy. > > What issues exactly are you thinking of? Memory changing underneath you. It can be dealt with by very careful sequencing only. >> That is why I'm suggesting using an in-kernel linearizer. > > Lots of complexity, ugh... Even Tejun's current scheme is better IMO. And then you get *no* privilege separation, for one thing, so why even bother doing it in userspace? -hpa |
From: Miklos S. <mi...@sz...> - 2008-08-29 07:32:18
|
On Thu, 28 Aug 2008, H. Peter Anvin wrote: > Miklos Szeredi wrote: > > On Thu, 28 Aug 2008, H. Peter Anvin wrote: > >> This is *hard* to get right, and we screw this up in the kernel with > >> painful regularity. The throught of having user-space processes, which > >> don't have access to the kernel locking primitives and functions like > >> copy_from_user() dealing with this stuff scares me crazy. > > > > What issues exactly are you thinking of? > > Memory changing underneath you. It can be dealt with by very careful > sequencing only. That's just handwaving. Apps don't normally change memory under system call arguments. Or if they do the only thing we ever guarantee is that the thing won't blow up in a big fireball. I don't see how getting the data from userspace is different from doing the same in the kernel. Care to explain? > >> That is why I'm suggesting using an in-kernel linearizer. > > > > Lots of complexity, ugh... Even Tejun's current scheme is better IMO. > > And then you get *no* privilege separation, for one thing, so why even > bother doing it in userspace? And with ioctls (at least if the filesystem supplies the linearizer instructions) you simply _cannot_ get proper privilege separation. Generic ioctl support will always be a privileged thing. Alternatively we can restrict ioctls. Most ioctls conform to some convention for encoding the format (size/in/out) in the command, no? Miklos |
From: Miklos S. <mi...@sz...> - 2008-08-29 07:59:26
|
On Fri, 29 Aug 2008, Tejun Heo wrote: > I'm not worried about the client accessing wrong memory regions or even > corrupting it. It's pointless to try to protect against that. From the > calling process's POV, it runs the same risk whether it calls an > in-kernel ioctl or a CUSE one and FUSE already has sufficient protection > against allowing unprivileged FS implementation to serve other users. Yes and no. Fuse allows this protection to be relaxed (-oallow_other), because it does provide quite good privilege separation. This ioctl thing breaks that, so we should disable ioctls with 'allow_other' or require the filesystem to be privileged. But the latter is not easy because mount(2) is always privileged, we don't know if the process calling fusermount was privileged or not. So, your current patch actually _introduces_ a security vulnerability with the 'allow_other' mount option. > What I'm worried about is the possibility of CUSE client being able to > break out of that privilege protection which is currently ensured by the > kernel. What do you call client? If you mean the app using the char dev, then I don't see how it could break out of any protection. > Also, what about containers? How would it work then? Dunno. Isn't there some transformation of pids going on, so that the global namespace can access pids in all containers but under a different alias? I do hope somethinig like this works, otherwise it's not only fuse that will break. Miklos |
From: Tejun H. <tj...@ke...> - 2008-08-29 08:13:17
|
Miklos Szeredi wrote: > On Fri, 29 Aug 2008, Tejun Heo wrote: >> I'm not worried about the client accessing wrong memory regions or even >> corrupting it. It's pointless to try to protect against that. From the >> calling process's POV, it runs the same risk whether it calls an >> in-kernel ioctl or a CUSE one and FUSE already has sufficient protection >> against allowing unprivileged FS implementation to serve other users. > > Yes and no. Fuse allows this protection to be relaxed > (-oallow_other), because it does provide quite good privilege > separation. This ioctl thing breaks that, so we should disable ioctls > with 'allow_other' or require the filesystem to be privileged. But > the latter is not easy because mount(2) is always privileged, we don't > know if the process calling fusermount was privileged or not. > > So, your current patch actually _introduces_ a security vulnerability > with the 'allow_other' mount option. Ah.. right. allow_other. Yeah, restricting ioctl implementation only to root or !allow_other sounds like a good idea. >> What I'm worried about is the possibility of CUSE client being able to >> break out of that privilege protection which is currently ensured by the >> kernel. > > What do you call client? If you mean the app using the char dev, then > I don't see how it could break out of any protection. I first used 'server' for userland [FC]USE server but then I noticed there were places in FUSE they were referred as clients so now I use 'client' for those and call the app using the FUSE fs the 'caller'. What are the established terms? Anyways, doing it directly from the server (or is it client) opens up a lot of new possibilities to screw up and I'd really much prefer staying in similar ballpark with other operations. Maybe we can restrict it to two stages (query size & transfer) and linear consecutive ranges but then again adding retry doesn't contribute too much to the complexity. Oh.. and BTW, the in-ioctl length coding is not used universally, so it can't be depended upon. >> Also, what about containers? How would it work then? > > Dunno. Isn't there some transformation of pids going on, so that the > global namespace can access pids in all containers but under a > different alias? I do hope somethinig like this works, otherwise it's > not only fuse that will break. I'm not sure either. Any idea who we should be asking about it? Thanks. -- tejun |
From: Miklos S. <mi...@sz...> - 2008-08-29 08:29:52
|
On Fri, 29 Aug 2008, Tejun Heo wrote: > I first used 'server' for userland [FC]USE server but then I noticed > there were places in FUSE they were referred as clients so now I use > 'client' for those and call the app using the FUSE fs the 'caller'. > What are the established terms? Umm - userspace filesystem - filesystem daemon - filesystem process - server Yes it's also a client of the fuse device, but that term is confusing. > Anyways, doing it directly from the server (or is it client) opens up a > lot of new possibilities to screw up and I'd really much prefer staying > in similar ballpark with other operations. Maybe we can restrict it to > two stages (query size & transfer) and linear consecutive ranges but > then again adding retry doesn't contribute too much to the complexity. > Oh.. and BTW, the in-ioctl length coding is not used universally, so it > can't be depended upon. I know it's not universal, some horrors I've seen in the old wireless interfaces. The question is: do we want to support such "extended" ioctls? For exmaple, does OSS have non-conformant ioctls? > >> Also, what about containers? How would it work then? > > > > Dunno. Isn't there some transformation of pids going on, so that the > > global namespace can access pids in all containers but under a > > different alias? I do hope somethinig like this works, otherwise it's > > not only fuse that will break. > > I'm not sure either. Any idea who we should be asking about it? Serge Hallyn and Eric Biederman. Miklos |
From: Tejun H. <tj...@ke...> - 2008-08-29 09:04:23
|
Miklos Szeredi wrote: > On Fri, 29 Aug 2008, Tejun Heo wrote: >> I first used 'server' for userland [FC]USE server but then I noticed >> there were places in FUSE they were referred as clients so now I use >> 'client' for those and call the app using the FUSE fs the 'caller'. >> What are the established terms? > > Umm > > - userspace filesystem > - filesystem daemon > - filesystem process > - server > > Yes it's also a client of the fuse device, but that term is confusing. Okay, will do s/client/server/g >> Anyways, doing it directly from the server (or is it client) opens up a >> lot of new possibilities to screw up and I'd really much prefer staying >> in similar ballpark with other operations. Maybe we can restrict it to >> two stages (query size & transfer) and linear consecutive ranges but >> then again adding retry doesn't contribute too much to the complexity. >> Oh.. and BTW, the in-ioctl length coding is not used universally, so it >> can't be depended upon. > > I know it's not universal, some horrors I've seen in the old wireless > interfaces. The question is: do we want to support such "extended" > ioctls? For exmaple, does OSS have non-conformant ioctls? OSS ioctls are all pretty simple and I think they all use the proper encoding. For the question, my answer would be yes (naturally). It will suck later when implementing some other device only to find out that there's this one ioctl that needs to dereference a pointer but there's no supported way to do it but everything else works. I don't think the performance or the complexity of specific ioctl implementation is of the determining importance as long as it can be made to work with minimal impact on the rest of the whole thing, so the current retry implementation. >>>> Also, what about containers? How would it work then? >>> Dunno. Isn't there some transformation of pids going on, so that the >>> global namespace can access pids in all containers but under a >>> different alias? I do hope somethinig like this works, otherwise it's >>> not only fuse that will break. >> I'm not sure either. Any idea who we should be asking about it? > > Serge Hallyn and Eric Biederman. Okay, cc'd both. Hello, Eric Biederman, Serge Hallyn. For implementing ioctl in FUSE, it's suggested that to access the address space of the caller directly from the FUSE server using its pid via /proc/pid/mem (or task/tid/mem). It's most likely that the calling process's tid will be used. As I don't know much about the containers, I'm not sure how such approach will play out when combined with containers. Can you enlighten us a bit? W/o containers, it will look like the following. FUSE ---------------- ^ | | | kernel ------ ioctl ----------- /dev/fuse ------------ | | userland | v --------------- ------------- | caller | | FUSE server |---> reads and writes | with tid CTID | | | /proc/PID/task/TID/mem --------------- ------------- The FUSE server gets task->pid. IIUC, if the FUSE server is not in a container, task->pid should work fine whether the caller is in container or not, right? And if the FUSE server is in a container, it's hell lot more complex and FUSE may have to map task->pid to what FUSE server would know if possible? Thanks. -- tejun |
From: Tejun H. <tj...@ke...> - 2008-09-01 12:03:59
|
Hello, Miklos Szeredi wrote: >> So why not just only support well defined ioctls and serialize them >> in the kernel and allow the receiving process to deserialize them? > > I'd like the idea of limiting to well behaved ioctls, but Tejun > doesn't... I'm not dead against it. I'm just a bit more inclined to my implementation (naturally), which means if you're dead against the current implementation, supporting only the proper ones definitely is an option, but comparing the pros and cons, I'm not quite convinced yet. Thanks. -- tejun |
From: Tejun H. <tj...@ke...> - 2008-09-03 14:41:36
|
Eric W. Biederman wrote: > I really think that if an ioctl is passing through the kernel we > should know how to parse and understand it's options. Otherwise > we won't have the option of doing backwards compatibility when something > changes, like we can with the 32->64bit ioctls. There's no reason 32->64bit can't be handled in userland? What's the difference? > That seems to imply that you need a stub in the kernel to handle > really weird ioctls. > > The upside is that because you know what the inputs and outputs are > and where the inputs and output are you can support that ioctl well > into the future, and you can do it with an unprivileged file > system server. Well, kernel stub kind of beats a lot of benefits of FUSE - no specific kernel dependencies, easy development and distribution, etc... Thanks. -- tejun |
From: Tejun H. <tj...@ke...> - 2008-10-14 08:24:32
|
Hello, Miklos. I'm about ready to send the next round of this patchset w/ mmap support, which I'm sure gonna stir up some discussion. :-) Several things I wanna hear your comments about. 1. I'll try to incorporate all other comments here but regarding ioctl I don't think we've reached any better solution, so I'm sticking with the original one. 2. You told me that the version branching in the userland library wasn't necessary. Can you explain to me when FUSE version bumping is necessary? 3. Any other things on you mind? Thanks. -- tejun |
From: Miklos S. <mi...@sz...> - 2008-10-14 10:15:20
|
Hi Tejun, On Tue, 14 Oct 2008, Tejun Heo wrote: > Hello, Miklos. > > I'm about ready to send the next round of this patchset w/ mmap support, > which I'm sure gonna stir up some discussion. :-) Several things I wanna > hear your comments about. Great. Just yesterday evening I was looking through your patches to see which ones I can submit for 2.6.28, and I've already applied 0001-FUSE-add-include-protectors.patch 0003-FUSE-implement-nonseekable-open.patch Comments about the others: 0002-FUSE-pass-nonblock-flag-to-client.patch this is not needed, f_flags are already passed to userspace for read and write. 0004-FUSE-implement-direct-lseek-support.patch this is trickier to get the interface right I think. If we want to allow filesystems to implement a custom lseek, then we also want them to keep track of the file position, which means we must differentiate between a write(2) and a pwrite(2) and similarly for reads. AFAICS this isn't needed for CUSE so we can leave this to later. 0005-FUSE-implement-ioctl-support.patch See below. 0006-FUSE-implement-unsolicited-notification.patch 0007-FUSE-implement-poll-support.patch This would be nice, but... I don't really like the fact that it uses the file handle. Could we have a separate "poll handle" that is returned in the POLL reply? > 1. I'll try to incorporate all other comments here but regarding ioctl I > don't think we've reached any better solution, so I'm sticking with the > original one. I still got qualms about this ioctl thing. One is the security aspect, but that could be dealt with. The other is that I really really don't want people to start implementing new custom ioctls for their filesystems, as I think that way lies madness. We could limit ioctls to CUSE and that would be fine with me. Or for non-CUSE users we could enforce the "standard" format where the type and length is encoded in the command number. I don't have any problems with the iterative way you implemented ioctls. We just need some additional restrictions to the current implementation, I think. > 2. You told me that the version branching in the userland library wasn't > necessary. Can you explain to me when FUSE version bumping is necessary? The version number has to be bumped anyway. But if you are only adding new functions to the end of fuse_operations and fuse_lowlevel_ops, then the interface can handle that, without needing new compatibility functions. > 3. Any other things on you mind? One other thing I was thinking about is that do we really need emulated char devices to be char devices? What I mean is, what would happen if instead of a char device /dev/dsp would be a regular file mounted on /dev/dsp (which implements all the necessary interfaces: ioctls, poll, etc)? Thanks, Miklos |