Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 1 Jan 2003 20:00:32 +0000 | From | Christoph Hellwig <> | Subject | Re: RFC/Patch - Implode devfs |
| |
On Wed, Jan 01, 2003 at 11:13:02AM -0800, Adam J. Richter wrote: > >I wonder whether some code uses struct devfs_entry * directly, at least > >I was tempted to do so in the scsi midlayer. > > Thankfully, struct devfs_entry* is an opaque pointer.
I know. IMHO it's still preferable to use struct devfs_entry * over devfs_handle_t like all the devfs mess does. This would work when devfs_handle_t suddenly points to something else.
The > struct is only defined in fs/devfs/base.c. Searching with > "find . -name '*.[ch]' | xargs grep -w devfs_entry" indicates > that everyone declares devfs_handle_t instead of "struct devfs_entry*", > so that's not a problem either.
OK.
> Your question prompted me to do a little bit of research. > I believe the list of routines that my reduced devfs does not > implement is as follows: > > devfs_get_handle > devfs_get_handle_from_inode > devfs_set_file_size > devfs_get_info > devfs_set_info > devfs_get_parent > devfs_get_first_child > devfs_get_next_sibling > devfs_get_name > devfs_register_tape > devfs_unregister_tape > devfs_alloc_major > devfs_dealloc_major > devfs_alloc_devnum > devfs_dealloc_devnum > > Storing this list in /tmp/names and grepping for these > identifiers shows only a small number of hits:
<snip>
At least the devfs_set_* / devfs_get_* can be removed easily when leaving the sn1 stuff danling. But I already discussed that with the responsible persons.
> >Is it supposed to work out of the box on previously (and for 2.4 use) > >non-devfs systems? I still don't plan to use devfs, but such an effort > >is really worth some debugging help.. > > Thanks for the encouragement.
So is the answer yes or no now? :)
> >Why do you want to allocate it statically? > > A few fields could be initialized statically. A few bytes > would be saved from memory allocation overhead. Cache locality would > improve infinitesemally. If all one-instance filesystems are changed > to do this, it will eliminate one memory allocation failure branch in > fs/super.c. Perhaps the same could be done with the root inode. I > know this is pretty marginal and might end up adding more complexity > than it would save. It's at the bottom of my TODO (or "to try") list.
Hmm. I don't think it's worth the effort, but if you can do it without introducing major ugliness you have my vote.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |