> While volume renaming isn't the most important feature on my plate, > I guarantee that my customers will expect it. At any rate though, it > can wait until the rest of the FS is stable.
People expect a *lot* of stuff. Different customers expect different things too. Sure, I'm familiar with that :) > It seems as though it might be worthwhile to develop a way to add > features to the MacFuse API independently of the Fuse API. Sure, MacFUSE isn't restricted by the FUSE API--it already does numerous things differently from other FUSE implementations. I have a whole bunch of new stuff I want to add for my own needs. Trust me, it's not for lack of wanting or lack of mechanisms that I'm not implementing volume rename. I need to prioritize things, that's all. > Just so you know where I'm coming from, my starting point is a > platform independent UDF file system engine (UDFAPI) , which has > already been ported to several different operating systems. It's not just a matter of porting it to different operating systems-- the fact that you are implementing your file system in user space changes things considerably. > I have this UDFAPI working (for the most part) within a kernel only > filesystem module, so I'm trying to replicate (as closely as > possible) the functionality of that filesystem. (I'm porting it to Replicating functionality shouldn't mean you have to (or *can*) do things the same way you do them in the kernel. > cluster_read is a KPI function which performs the read directly, > providing efficient support for UBC - in my case bypassing > udfapi__read_file, and all of it's associated cruft > (LOG_KERNEL_MALLOC, uiomove, etc...). I still don't quite understand--do you want cluster_read (or equivalent) to be forwarded to user space? That's not going to happen within MacFUSE. MacFUSE itself uses cluster_read (and I/O goes through the buffer cache). > It may be that none of this is actually necessary, or desired with > MacFuse - given that you're already supporting the UBC for file I/O. Why not look at MacFUSE source (it *is* open source after all) and see how it is doing things? I would say do that first so you don't end up making incorrect assumptions or design decisions for your work. Amit --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
