On Tue, Dec 31, 2002 at 06:24:22PM -0800, Adam J. Richter wrote:
> The following patch replaces devfs with a ramfs-derived
> implementation which is under one quarter the size although it
> eliminates certain functionality.
>
> wc -l *.c Makefile size (text + data + bss)
>
> devfs 3614 lines 25,863 bytes
> mini-devfs 629 lines 5,367 bytes
> Reduction 5.7x 4.8x
Wow, that looks really cool! I just wonder where viro is hiding the last
weeks, he promised more devfs API cleanups that likely clash with
your changes.
> 3. devfs_handle_t is now a synonym for struct dentry*.
I wonder whether some code uses struct devfs_entry * directly, at least
I was tempted to do so in the scsi midlayer.
> 4. A lot of the devfs routines are unimplemented. I haven't
> noticed much code that uses them, and I'm not sure that any code
> really should. I think arch/ia64/sn uses devfs_get_first_child,
> devfs_get_next_sibling. I need to understand what if any of the
> other routines are really necessary and why (for example, why can't
> we use struct dentry). My computer seems to run fine without them.
The hcl code in arch/ia64/sn/ is supposed to get replaced by a filesystem
on it's own once the sn port is properly updated for 2.5/2.6.
> First of all, I'd like to debug this code and I'd welcome any
> help.
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..
> I think I'd like to change fs/super.c slightly to make it
> easier to statically allocate the struct super_block for filesystems
> that can have only one instance even if they are mounted in multiple
> locations (devfs, procfs, sysfs, usbdevfs, etc.).
Why do you want to allocate it statically?
> @@ -24,7 +24,11 @@
> #define DEVFS_SPECIAL_CHR 0
> #define DEVFS_SPECIAL_BLK 1
>
> +#ifdef CONFIG_DEVFS_SMALL
> +typedef struct dentry * devfs_handle_t;
> +#else
> typedef struct devfs_entry * devfs_handle_t;
> +#endif
Do you really need to keep both around?
> +/* On success, returns with (*parent_inode)->i_sem taken. */
> +static int devfs_decode(devfs_handle_t dir, const char *name, int is_dir,
> + struct inode **parent_inode, struct dentry **dentry)
Do we really have to support this?
> +++ linux/fs/devfs2/numspace.c 2002-12-25 17:44:14.000000000 -0800
> @@ -0,0 +1,76 @@
> +#include <linux/module.h>
> +#include <linux/vmalloc.h>
> +#include <linux/devfs_fs_kernel.h>
> +
> +/**
> + * devfs_alloc_unique_number - Allocate a unique (positive) number.
> + * @space: The number space to allocate from.
> + *
> + * Returns the allocated unique number, else a negative error code.
> + * This routine is thread safe and may block.
> + */
> +
> +int devfs_alloc_unique_number (struct unique_numspace *space)
Remove the devfs_ prefix here (it's not devfs-specific at all) and
convert to sane indentation?
-
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/
This archive was generated by hypermail 2b29 : Tue Jan 07 2003 - 22:00:14 EST