Skip to contentSkip to conversation

remove unused funcion proc_mknod

PATCH In review Christoph Hellwig 4 participants 7 messages May 5, 2003 – May 9, 2003 Proc filesystem

lore
Share & tools
lore

Christoph Hellwig

author
#0 lore raw

PATCH 1/1 remove unused funcion proc_mknod

Not used currently and a rather bad idea in general..

fs/proc/generic.c +0 -16
@@ -566,22 +566,6 @@
 	return ent;
 }
 
-struct proc_dir_entry *proc_mknod(const char *name, mode_t mode,
-		struct proc_dir_entry *parent, kdev_t rdev)
-{
-	struct proc_dir_entry *ent;
-
-	ent = proc_create(&parent,name,mode,1);
-	if (ent) {
-		ent->rdev = rdev;
-		if (proc_register(parent, ent) < 0) {
-			kfree(ent);
-			ent = NULL;
-		}
-	}
-	return ent;
-}
-
 struct proc_dir_entry *proc_mkdir(const char *name, struct proc_dir_entry *parent)
 {
 	struct proc_dir_entry *ent;

===== fs/proc/root.c 1.11 vs edited =====

fs/proc/root.c +0 -1
@@ -151,7 +151,6 @@
 EXPORT_SYMBOL(proc_sys_root);
 #endif
 EXPORT_SYMBOL(proc_symlink);
-EXPORT_SYMBOL(proc_mknod);
 EXPORT_SYMBOL(proc_mkdir);
 EXPORT_SYMBOL(create_proc_entry);
 EXPORT_SYMBOL(remove_proc_entry);

===== include/linux/proc_fs.h 1.15 vs edited =====

include/linux/proc_fs.h +0 -4
@@ -133,8 +133,6 @@
 
 extern struct proc_dir_entry *proc_symlink(const char *,
 		struct proc_dir_entry *, const char *);
-extern struct proc_dir_entry *proc_mknod(const char *,mode_t,
-		struct proc_dir_entry *,kdev_t);
 extern struct proc_dir_entry *proc_mkdir(const char *,struct proc_dir_entry *);
 
 static inline struct proc_dir_entry *create_proc_read_entry(const char *name,

@@ -182,8 +180,6 @@
 static inline void remove_proc_entry(const char *name, struct proc_dir_entry *parent) {};
 static inline struct proc_dir_entry *proc_symlink(const char *name,
 		struct proc_dir_entry *parent,char *dest) {return NULL;}
-static inline struct proc_dir_entry *proc_mknod(const char *name,mode_t mode,
-		struct proc_dir_entry *parent,kdev_t rdev) {return NULL;}
 static inline struct proc_dir_entry *proc_mkdir(const char *name,
 	struct proc_dir_entry *parent) {return NULL;}
#1 lore raw
Quoted 1 line · Christoph Hellwig

Not used currently and a rather bad idea in general..

That is true, but note that ALAS^H^HSA creates device nodes in /proc manually. IOW, removal of proc_mknod() won't solve anything. The real question is whether we should allow device nodes on procfs. If we should not allow them, ALSA needs API changes. If we should, it'd be better to have creation of such nodes explicit (and if ALSA keeps doing that, it should switch to calling proc_mknod()).

author
#2 lore raw
Quoted 5 lines · On Mon, May 05, 2003 at 08:22:48PM +0100…

manually. IOW, removal of proc_mknod() won't solve anything. The real question is whether we should allow device nodes on procfs. If we should not allow them, ALSA needs API changes. If we should, it'd be better to have creation of such nodes explicit (and if ALSA keeps doing that, it should switch to calling proc_mknod()).

We shouldn't. It's very bad style. And it seems ALSA also registers a chardev and devfs entries for that stuff.

Jaroslav, can we just drop that junk or is it still used by userland. And if yes how long will it take to get an alsa-libs release out to not rely on it?

#3 lore raw
Quoted 3 lines · Christoph Hellwig

Jaroslav, can we just drop that junk or is it still used by userland. And if yes how long will it take to get an alsa-libs release out to not rely on it?

Not commenting on this issue specifically, but in general, alsa-lib can be used to mitigate the effect of kernel changes on userland.

This was a big selling point for ALSA, back when we were trying to decide what to do about OSS.

Jeff

#4 lore raw
In reply to Christoph Hellwig
Quoted 7 lines · Christoph Hellwig
Quoted 5 lines · On Mon, May 05, 2003 at 08:22:48PM +0100…

manually. IOW, removal of proc_mknod() won't solve anything. The real question is whether we should allow device nodes on procfs. If we should not allow them, ALSA needs API changes. If we should, it'd be better to have creation of such nodes explicit (and if ALSA keeps doing that, it should switch to calling proc_mknod()).

Quoted 6 lines

We shouldn't. It's very bad style. And it seems ALSA also registers a chardev and devfs entries for that stuff.

Jaroslav, can we just drop that junk or is it still used by userland. And if yes how long will it take to get an alsa-libs release out to not rely on it?

alsa-lib doesn't rely on it at all. The devices in /dev/snd/ might be created in these ways:

1) static - using the mknod command
2) using devfs
3) link /dev/snd to /proc/asound/dev

We prefered the third solution because we were changing heavily the device minor numbers in the past. We can remove the proc dynamic device creating from our code now. I agree, this code should not be in the kernel tree.

Jaroslav

-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs

author
#5 lore raw
Quoted 10 lines · Jaroslav Kysela

alsa-lib doesn't rely on it at all. The devices in /dev/snd/ might be created in these ways:

1) static - using the mknod command
2) using devfs
3) link /dev/snd to /proc/asound/dev

We prefered the third solution because we were changing heavily the device minor numbers in the past. We can remove the proc dynamic device creating from our code now. I agree, this code should not be in the kernel tree.

Okay. Will you submit the removal as part of the next alsa merge?

#6 lore raw
Quoted 8 lines · Christoph Hellwig
Quoted 7 lines · Jaroslav Kysela

alsa-lib doesn't rely on it at all. The devices in /dev/snd/ might be created in these ways:

1) static - using the mknod command
2) using devfs
3) link /dev/snd to /proc/asound/dev

Quoted 5 lines
Quoted 3 lines

We prefered the third solution because we were changing heavily the device minor numbers in the past. We can remove the proc dynamic device creating from our code now. I agree, this code should not be in the kernel tree.

Okay. Will you submit the removal as part of the next alsa merge?

Sure. I'll do it ASAP.

Jaroslav

-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs