Not used currently and a rather bad idea in general..
--- 1.21/fs/proc/generic.c Fri Apr 25 17:46:19 2003
+++ edited/fs/proc/generic.c Mon May 5 17:26:34 2003
@@ -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 =====
--- 1.11/fs/proc/root.c Sat Sep 28 17:36:29 2002
+++ edited/fs/proc/root.c Mon May 5 17:26:26 2003
@@ -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 =====
--- 1.15/include/linux/proc_fs.h Tue Aug 13 01:20:00 2002
+++ edited/include/linux/proc_fs.h Mon May 5 17:26:44 2003
@@ -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;}
On Mon, May 05, 2003 at 07:00:45PM +0200, Christoph Hellwig wrote:
> 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()).
On Mon, May 05, 2003 at 08:22:48PM +0100, [email protected] wrote:
> 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?
Christoph Hellwig wrote:
> 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
On Mon, 5 May 2003, Christoph Hellwig wrote:
> On Mon, May 05, 2003 at 08:22:48PM +0100, [email protected] wrote:
> > 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?
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
On Fri, May 09, 2003 at 01:43:20PM +0200, Jaroslav Kysela wrote:
> 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?
On Fri, 9 May 2003, Christoph Hellwig wrote:
> On Fri, May 09, 2003 at 01:43:20PM +0200, Jaroslav Kysela wrote:
> > 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?
Sure. I'll do it ASAP.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs