On Wed, Nov 19, 2008 at 12:06 AM, Santiago <santi@xxxxxx> wrote: > Thank you very much for your attention! > >> u posted right...but i don't understand your question > > OK - that's reasonable, as I actually don't know, how to ask the right way. > >> u can: >> >> a. use FUSE >> b. use libfs >> c. use the model how ext3 and jfs worked together.....writing to ext3 >> always entailed writing to jfs journalling. > > Hm, don't know, how much I already understood from the kernel stuff. > > One of the requirements to the "part", I'd like to create is, that it should > be totally transparent to the users of the filesystem, means to existing > applications. > So I don't know, whether FUSE or libfs are right. Both are for userspace > programs - aren't they? > > The whole story is to big for me to realize in one step, so let me try to > explain, how I imagine the first step: > > I'd like to write a fs-module (like aufs or unionfs), let me call it simplefs, > just to give it a name, wich works between userprogram and real filesystem. > The final simplefs should manage several different "real" filesystems, where > it has one private filesystem and all others are public. > The private filesystem should be configured by the option-string of fstab. So > an entry for my simplefs might be something like: > /dev/virtual /mountPoint simplefs > defaults,pd=/dev/sda1,pt=ext3,po="defaults" ... > > where pd stands for 'private device', pt for 'private type' and po > for 'private options'. > > What I like to do in the first step is mounting that device on a subdir > of /mountPoint i.e. /mountPoint/private > > Any directory operations should go to the mounted device as if that was > mounted at /mountPoint and on a read-operation to a real file I would like to > return 'hello world'. In the second step I'd like to realize a trigger to > userspace before returning 'hello world'. All further steps will extend the > read-function of a file - all directory or path-searching will stay > unchanged. > > Currently I'm done with the option parsing and I also scanned the superblocks > of all known devices to find the superblock of the given type. > What I don't know, is how I should create the internal datastructures (from > the strings I got from fstab) to mount the device and how I create a > null-wrapper. > I tried to wrap all functions with a kprint-message, but some functions crash > the system. So it's not possible to just route the parameters to the other > function. > I think, it was a read-function with a __user pointer that crashed. > > Also I have a crash on unloading the module - it tell's me, that I did not > unregister a kernel object, but I did not create any yet. > > So - there seems to be a lot of hidden stuff, which I have no idea on how to > get rid of. And most tutorials about filesystems, I found, are outdated and > broken. > > I hope, I was a bit better this time in explaining my problem :) Looks interesting.......and yes it is much clearer from the first time. Do you mind sharing your code so that others can have a look ? Can you upload it somewhere ? Thanks - Manish > > kind regards > > Santiago > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
