On 24/04/10 05:23PM, Christian Brauner wrote: > > I don't think &dev makes sense here - it was passed by value so its > > address won't make sense outside the current context, right?. It seems > > I don't follow, we only need that address to be valid until sget_dev() > returns as sget_key isn't used anymore. And we store the value, not the > address. Other than that it's a bit ugly it's fine afaict. Related > issues would exist with fuse or gfs2 where the lifetime of the key ends > right after the respective sget call returns. We could smooth this out > here by storing the value in the pointer via > #define devt_to_sget_key(dev) ((void *)((uintptr_t)(dev))) > #define sget_key_to_devt(key) ((dev_t)((uintptr_t)(key))) That's the gist of what my patch was trying to do, but it was messy because void * is 8 bytes and dev_t is 4 bytes, so casting got a bit messy (not even including my fubar-ness).. Not that my vote is important, but I would heartily vote for storing the dev_t in the sget_key rather than having the key be a void * to a soon-to-be-reused stack. Future developers would have an easier time with that, if I'm any indication. > but I'm not sure it's necessary. Unless I'm really missing something. I must admit it hadn't even occurred to me that a void * to a dev_t would be stored long-term in fs_context even though it is only short- term valid. But you're right, that works provided the validity lifespan isn't violated - which it isn't here. I was around in the K&R C time frame, and... well, never mind... Thanks for your patience with me on this. I guess my sget_dev() was failing to find my old superblocks for a different reason - like I thought they still existed but was mistaken. You may see a Q or two from me on the old famfs thread soon, prior to v2 of that... Thank you, John
