Re: [RFC PATCH] add filesystem subtype support
> >-static struct file_system_type **find_filesystem(const char *name)
> >+static struct file_system_type **find_filesystem(const char *name, unsigned
> >len)
> > {
> > struct file_system_type **p;
> > for (p=_systems; *p; p=&(*p)->next)
> >-if (strcmp((*p)->name,name) == 0)
> >+if (strlen((*p)->name) == len &&
> >+strncmp((*p)->name, name, len) == 0)
> > break;
> > return p;
> > }
>
> Question btw, why does this function return a struct file_system_type ** at
> all? Would not struct file_system_type * suffice?
It's used in register_filesystem() to get the end of the list pointer.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] add filesystem subtype support
Hi,
On Feb 12 2007 12:50, Miklos Szeredi wrote:
>Index: linux/fs/filesystems.c
>===
>--- linux.orig/fs/filesystems.c2007-02-12 12:42:55.0 +0100
>+++ linux/fs/filesystems.c 2007-02-12 12:43:00.0 +0100
>@@ -42,11 +42,12 @@ void put_filesystem(struct file_system_t
> module_put(fs->owner);
> }
>
>-static struct file_system_type **find_filesystem(const char *name)
>+static struct file_system_type **find_filesystem(const char *name, unsigned
>len)
> {
> struct file_system_type **p;
> for (p=_systems; *p; p=&(*p)->next)
>- if (strcmp((*p)->name,name) == 0)
>+ if (strlen((*p)->name) == len &&
>+ strncmp((*p)->name, name, len) == 0)
> break;
> return p;
> }
Question btw, why does this function return a struct file_system_type ** at
all? Would not struct file_system_type * suffice?
I like the idea. Then the "real filesystem type" (e.g. sshfs) pops up in the
fstype field in getmntent, and `df`, for example.
Jan
--
ft: http://freshmeat.net/p/chaostables/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] add filesystem subtype support
> > There's a slight problem with filesystem type representation in fuse > > based filesystems. > > > > >From the kernel's view, there are just two filesystem types: fuse and > > fuseblk. From the user's view there are lots of different filesystem > > types. The user is not even much concerned if the filesystem is fuse > > based or not. > > Yes. Those who are concerned with the fstype and mount like > > mount -t fstype device mountpoint > > apparently expect mount/fstab line like > > device mountpoint fstype ... The problem with supporting /dev/hda1 /mnt/windows ntfs-3g rw,... type syntax in /proc/mounts is that it would add much more complexity to the kernel. The same could be achieved in userspace by teaching the mount utility about special filesystems like ntfs-3g. This patch aims for the minium footprint for a feature, that really doesn't concern the kernel at all. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] add filesystem subtype support
Hi, On Mon, 12 Feb 2007, Miklos Szeredi wrote: > There's a slight problem with filesystem type representation in fuse > based filesystems. > > >From the kernel's view, there are just two filesystem types: fuse and > fuseblk. From the user's view there are lots of different filesystem > types. The user is not even much concerned if the filesystem is fuse > based or not. Yes. Those who are concerned with the fstype and mount like mount -t fstype device mountpoint apparently expect mount/fstab line like device mountpoint fstype ... Of course the fstype could be fuse.subtype or fuseblk.subtype but that would add a needless complexity (also, for example ntfs-3g uses both and it decides run-time which one to use). > So there's a conflict of interest in how this should be > represented in fstab, mtab and /proc/mounts. > > The current scheme is to encode the real filesystem type in the mount > source. So an sshfs mount looks like this: > > [EMAIL PROTECTED]:/ /mnt/serverfuse rw,nosuid,nodev,... > > This url-ish syntax works OK for sshfs and similar filesystems. > However for block device based filesystems (ntfs-3g, zfs) it doesn't > work, since the kernel expects the mount source to be a real device > name. > > A possibly better scheme would be to encode the real type in the type > field as "type.subtype". So fuse mounts would look like this: > > /dev/hda1 /mnt/windows fuseblk.ntfs-3g rw,... > [EMAIL PROTECTED]:/ /mnt/serverfuse.sshfsrw,nosuid,nodev,... I think it's definitely an improvement because it solves real problems, though perhaps not the way users would expect. Szaka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] add filesystem subtype support
Hi, On Mon, 12 Feb 2007, Miklos Szeredi wrote: There's a slight problem with filesystem type representation in fuse based filesystems. From the kernel's view, there are just two filesystem types: fuse and fuseblk. From the user's view there are lots of different filesystem types. The user is not even much concerned if the filesystem is fuse based or not. Yes. Those who are concerned with the fstype and mount like mount -t fstype device mountpoint apparently expect mount/fstab line like device mountpoint fstype ... Of course the fstype could be fuse.subtype or fuseblk.subtype but that would add a needless complexity (also, for example ntfs-3g uses both and it decides run-time which one to use). So there's a conflict of interest in how this should be represented in fstab, mtab and /proc/mounts. The current scheme is to encode the real filesystem type in the mount source. So an sshfs mount looks like this: [EMAIL PROTECTED]:/ /mnt/serverfuse rw,nosuid,nodev,... This url-ish syntax works OK for sshfs and similar filesystems. However for block device based filesystems (ntfs-3g, zfs) it doesn't work, since the kernel expects the mount source to be a real device name. A possibly better scheme would be to encode the real type in the type field as type.subtype. So fuse mounts would look like this: /dev/hda1 /mnt/windows fuseblk.ntfs-3g rw,... [EMAIL PROTECTED]:/ /mnt/serverfuse.sshfsrw,nosuid,nodev,... I think it's definitely an improvement because it solves real problems, though perhaps not the way users would expect. Szaka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] add filesystem subtype support
There's a slight problem with filesystem type representation in fuse based filesystems. From the kernel's view, there are just two filesystem types: fuse and fuseblk. From the user's view there are lots of different filesystem types. The user is not even much concerned if the filesystem is fuse based or not. Yes. Those who are concerned with the fstype and mount like mount -t fstype device mountpoint apparently expect mount/fstab line like device mountpoint fstype ... The problem with supporting /dev/hda1 /mnt/windows ntfs-3g rw,... type syntax in /proc/mounts is that it would add much more complexity to the kernel. The same could be achieved in userspace by teaching the mount utility about special filesystems like ntfs-3g. This patch aims for the minium footprint for a feature, that really doesn't concern the kernel at all. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] add filesystem subtype support
Hi,
On Feb 12 2007 12:50, Miklos Szeredi wrote:
Index: linux/fs/filesystems.c
===
--- linux.orig/fs/filesystems.c2007-02-12 12:42:55.0 +0100
+++ linux/fs/filesystems.c 2007-02-12 12:43:00.0 +0100
@@ -42,11 +42,12 @@ void put_filesystem(struct file_system_t
module_put(fs-owner);
}
-static struct file_system_type **find_filesystem(const char *name)
+static struct file_system_type **find_filesystem(const char *name, unsigned
len)
{
struct file_system_type **p;
for (p=file_systems; *p; p=(*p)-next)
- if (strcmp((*p)-name,name) == 0)
+ if (strlen((*p)-name) == len
+ strncmp((*p)-name, name, len) == 0)
break;
return p;
}
Question btw, why does this function return a struct file_system_type ** at
all? Would not struct file_system_type * suffice?
I like the idea. Then the real filesystem type (e.g. sshfs) pops up in the
fstype field in getmntent, and `df`, for example.
Jan
--
ft: http://freshmeat.net/p/chaostables/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] add filesystem subtype support
-static struct file_system_type **find_filesystem(const char *name)
+static struct file_system_type **find_filesystem(const char *name, unsigned
len)
{
struct file_system_type **p;
for (p=file_systems; *p; p=(*p)-next)
-if (strcmp((*p)-name,name) == 0)
+if (strlen((*p)-name) == len
+strncmp((*p)-name, name, len) == 0)
break;
return p;
}
Question btw, why does this function return a struct file_system_type ** at
all? Would not struct file_system_type * suffice?
It's used in register_filesystem() to get the end of the list pointer.
Miklos
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
