Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

Quoted 8 lines · David Ford

Quoted 5 lines · Alan Cox
Quoted 4 lines
10. To Do But Non Showstopper
* PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is reliable)
+ PCMCIA crashes on unloading pci_socket

Quoted 7 lines

Quoted 1 line
The pci_socket crash is fixed it seems
Not unless it was fixed in test10 release. I have a PC LinkSys dual 10/100 and 56K card that will kill the machine if you physically pull it out no matter what cardctl/module steps are taken.
It uses the ne2k and serial drivers.

Part of that might be that serial doesn't support hotplug without patching.

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-04 00:15 UTC #4 lore raw

Quoted 8 lines

Quoted 5 lines
Not unless it was fixed in test10 release. I have a PC LinkSys dual 10/100 and 56K card that will kill the machine if you physically pull it out no matter what cardctl/module steps are taken.
It uses the ne2k and serial drivers.
Part of that might be that serial doesn't support hotplug without patching.

Linksys rings a bell with an outstandng 2.2 lockup on pcmcia. I think this might be a driver bug ?

Quoted 1 line

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-04 01:25 UTC #5 lore raw

Quoted 5 lines · Alan Cox

Quoted 5 lines
Quoted 5 lines
Not unless it was fixed in test10 release. I have a PC LinkSys dual 10/100 and 56K card that will kill the machine if you physically pull it out no matter what cardctl/module steps are taken.

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
It uses the ne2k and serial drivers.
Part of that might be that serial doesn't support hotplug without patching.
Linksys rings a bell with an outstandng 2.2 lockup on pcmcia. I think this might be a driver bug ?

On 2.2.x, possibly.

On 2.4.x: 1) insert CardBus serial or modem card, that reports itself as PCI_CLASS_COMMUNICATION_SERIAL. 2) modprobe serial, it sees and registers the PCI serial port. 3) eject card, which serial.c doesn't presently notice. ...

Jeff

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Ford

2000-11-04 02:39 UTC #6 lore raw

Quoted 4 lines · Alan Cox

Quoted 2 lines
Quoted 2 lines
Not unless it was fixed in test10 release. I have a PC LinkSys dual 10/100 and 56K card that will kill the machine if you physically pull it out no matter what
Linksys rings a bell with an outstandng 2.2 lockup on pcmcia. I think this might be a driver bug ?

I suspect it might be, I also think it may be getting the wrong voltage or it's poorly designed hardware. It gets hot enough to make a blister if you don't handle it carefully.

It works fine all the while installed, goes for days on end, even tho it gets incredibly hot. :)

-d

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

[email protected]

author

2000-11-07 19:21 UTC #7 lore raw

Date: Fri, 03 Nov 2000 16:10:50 -0500
From: Jeff Garzik <[email protected]>

Part of that might be that serial doesn't support hotplug without patching.

Did the patch which I sent out a few weeks ago actually work? I haven't had time to get back to it, but I now have a cardbus card, so it's on my todo list....

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-03 21:38 UTC #8 lore raw

Quoted 8 lines · Alan Cox

Quoted 5 lines
* Check all devices use resources properly (Everyone now has to use request_region and check the return since we no longer single thread driver inits in all module cases. Also memory regions are now requestable and a lot of old drivers dont know this yet. -- Alan Cox)
Folks have done most of the common drivers. So its not really a show stopper now just a 'clean up'

s/check_region/request_region/ is moving along, but there is still a ways to go. I agree with "folks have done most of the common drivers"

I have seen very few additions of request_mem_region, though.

Quoted 5 lines

Quoted 3 lines
* Issue with notifiers that try to deregister themselves? (lnz; notifier locking change by Garzik should backed out, according to Jeff)
and according to Alan

Fixed for a couple versions now.

Quoted 5 lines

Quoted 3 lines
* Spin doing ioctls on a down netdeice as it unloads == BOOM (prumpf, Alan Cox) Possible other net driver SMP issues (andi kleen)
Turns out to be safe according to Jeff and ANK

To avoid Andi confusing the issue :) ...

1) The first item listed does not exist

2) the second item listed exists -- many net drivers are not SMP. They are most of the way there, but there are still small races which exist in some drivers.

Jeff

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Ford

2000-11-03 21:57 UTC #9 lore raw

The odd part is that it used to work "way back when". Was this just a fluke?

-d

Quoted 8 lines · Jeff Garzik

Quoted 5 lines
Not unless it was fixed in test10 release. I have a PC LinkSys dual 10/100 and 56K card that will kill the machine if you physically pull it out no matter what cardctl/module steps are taken.
It uses the ne2k and serial drivers.
Part of that might be that serial doesn't support hotplug without patching.

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

Jeff Garzik

2000-11-04 01:28 UTC #10 lore raw

Quoted 1 line · David Ford

The odd part is that it used to work "way back when". Was this just a fluke?

That may have been back in the legacy days. Ejecting ne2k should be ok as long as you are using ne2k-pci or pcnet_cs. Eject serial looks like bad news unless you are using serial_cs (which is impossible at the moment, AFAIK).

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Paul Gortmaker

2000-11-06 20:28 UTC #11 lore raw

Quoted 8 lines · Jeff Garzik

Quoted 6 lines · Alan Cox
Quoted 5 lines
* Check all devices use resources properly (Everyone now has to use request_region and check the return since we no longer single thread driver inits in all module cases. Also memory regions are now requestable and a lot of old drivers dont know this yet. -- Alan Cox)

Quoted 7 lines

Quoted 2 lines
Folks have done most of the common drivers. So its not really a show stopper now just a 'clean up'
s/check_region/request_region/ is moving along, but there is still a ways to go. I agree with "folks have done most of the common drivers"
I have seen very few additions of request_mem_region, though.

Something which I forgot to add when mentioning my ioremap patch is that you can pretty much forget about adding request_mem_region() to the same drivers since both changes are in the same spot of code and doing one without doing the other is kind of silly. (i.e. the patches I have for 8390 based drivers do both at once).

Although simply having a dev->vmem [or dev->base] added to struct netdevice in 2.4.0, as was discussed many months ago(*) might go a long way in allowing driver back-compatibility from 2.5.x into 2.4.x - probably worthwhile.

(*) Search <[email protected]>
in any linux-net mailing list archive of Dec 1999.

Paul.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[email protected]

author

2000-11-07 19:18 UTC #12 lore raw

Date: Fri, 3 Nov 2000 15:53:34 +0000 (GMT)
From: Alan Cox <[email protected]>

Quoted 2 lines

* AIC7xxx doesnt work non PCI ? (Doug says OK, new version due anyway)

This is now in Justin Gibbs hand but will take time to move on. Doug confirmed his current code is now merged too.

Does this mean that the problem has been fixed in the latest 2.4 tree? i.e., Does Doug's current code have the problem fixed?

Quoted 3 lines

* Issue with notifiers that try to deregister themselves? (lnz; notifier locking change by Garzik should backed out, according to Jeff)

and according to Alan

But it hasn't been backed out yet, correct?

Someone one send a patch to Linus?

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-07 19:22 UTC #13 lore raw

Quoted 7 lines · [email protected] wrote:

Quoted 3 lines
* Issue with notifiers that try to deregister themselves? (lnz; notifier locking change by Garzik should backed out, according to Jeff)
and according to Alan
But it hasn't been backed out yet, correct?

It has been backed out. Notifier register and deregister are locked, but not notifier call.

Signature · 8 lines

Jeff Garzik             | "When I do this, my computer freezes."
Building 1024           |          -user
MandrakeSoft            | "Don't do that."
                        |          -level 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-07 19:24 UTC #14 lore raw

Quoted 10 lines · [email protected] wrote:

Date: Fri, 03 Nov 2000 16:10:50 -0500
From: Jeff Garzik <[email protected]>
Part of that might be that serial doesn't support hotplug without patching.
Did the patch which I sent out a few weeks ago actually work? I haven't had time to get back to it, but I now have a cardbus card, so it's on my todo list....

I do not have CardBus card, so I can't test it. Did you make sure to have a pci_driver::remove function? That is a requirement for PCI hotplug. Otherwise, your driver's probe routine will never be called.

I have a built-in Xircom modem on my Toshiba laptop, and it works great with your patch.

Jeff

Signature · 8 lines

Jeff Garzik             | "When I do this, my computer freezes."
Building 1024           |          -user
MandrakeSoft            | "Don't do that."
                        |          -level 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Philipp Rumpf

2000-11-03 16:10 UTC #15 lore raw

Quoted 5 lines

3. Security
* Fix module remove race bug (still to be done: TTY, ldisc, I2C, video_device - Al Viro) (Rogier Wolff will handle ATM)

TBD: sysctl, kernel_thread

* drivers/input/mousedev.c dereferences userspace pointers directly. We should make this fail for a bit to catch those bugs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen

2000-11-03 16:56 UTC #16 lore raw

Quoted 5 lines

Quoted 3 lines
* Spin doing ioctls on a down netdeice as it unloads == BOOM (prumpf, Alan Cox) Possible other net driver SMP issues (andi kleen)
Turns out to be safe according to Jeff and ANK

It is not safe, just not worse than 2.2.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[email protected]

2000-11-03 19:04 UTC #17 lore raw

Hello!

Quoted 1 line

It is not safe, just not worse than 2.2.

Andi...... 8)

That issue, which was meant here, it is 100% safe.

I start to suspect you did not look into this code since 2.2. I acn assume that nothing has changed in ISDN,
in other drivers big changes happened. 8)

Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James Simmons

2000-11-03 18:10 UTC #18 lore raw

In reply to James Simmons

Quoted 3 lines

* VGA Console can cause SMP deadlock when doing printk {CRITICAL} (Keith Owens)

Still not fixed :-( Here is the patch again. Keith give it a try and tell me if it solves your problems.

vgacon.c renamed from vgacon.c.orig +20 ~~-20~~

@@ -46,11 +46,13 @@
 #include <linux/malloc.h>
 #include <linux/vt_kern.h>
 #include <linux/selection.h>
+#include <linux/spinlock.h>
 #include <linux/ioport.h>
 #include <linux/init.h>
 
 #include <asm/io.h>
 
+static spinlock_t vga_lock = SPIN_LOCK_UNLOCKED;
 
 #define BLANK 0x0020

@@ -152,8 +154,7 @@
 	 * ddprintk might set the console position from interrupt
 	 * handlers, thus the write has to be IRQ-atomic.
 	 */
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&vga_lock, flags);	
 
 #ifndef SLOW_VGA
 	v1 = reg + (val & 0xff00);

@@ -166,7 +167,7 @@
 	outb_p(reg+1, vga_video_port_reg);
 	outb_p(val & 0xff, vga_video_port_val);
 #endif
-	restore_flags(flags);
+	spin_unlock_irqrestore(&vga_lock, flags);
 }
 
 static const char __init *vgacon_startup(void)

@@ -415,7 +416,7 @@
 	if ((from == lastfrom) && (to == lastto)) return;
 	lastfrom = from; lastto = to;
 
-	save_flags(flags); cli();
+	spin_lock_irqsave(&vga_lock, flags);
 	outb_p(0x0a, vga_video_port_reg);		/* Cursor start */
 	curs = inb_p(vga_video_port_val);
 	outb_p(0x0b, vga_video_port_reg);		/* Cursor end */

@@ -428,7 +429,7 @@
 	outb_p(curs, vga_video_port_val);
 	outb_p(0x0b, vga_video_port_reg);		/* Cursor end */
 	outb_p(cure, vga_video_port_val);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&vga_lock, flags);
 }
 
 static void vgacon_cursor(struct vc_data *c, int mode)

@@ -533,11 +534,11 @@
 {
 	/* save original values of VGA controller registers */
 	if(!vga_vesa_blanked) {
-		cli();
+		spin_lock_irq(&vga_lock);
 		vga_state.SeqCtrlIndex = inb_p(seq_port_reg);
 		vga_state.CrtCtrlIndex = inb_p(vga_video_port_reg);
 		vga_state.CrtMiscIO = inb_p(video_misc_rd);
-		sti();
+		spin_unlock_irq(&vga_lock);
 
 		outb_p(0x00,vga_video_port_reg);	/* HorizontalTotal */
 		vga_state.HorizontalTotal = inb_p(vga_video_port_val);

@@ -561,7 +562,7 @@
 
 	/* assure that video is enabled */
 	/* "0x20" is VIDEO_ENABLE_bit in register 01 of sequencer */
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p(0x01,seq_port_reg);
 	outb_p(vga_state.ClockingMode | 0x20,seq_port_val);

@@ -598,13 +599,13 @@
 	/* restore both index registers */
 	outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
 	outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
-	sti();
+	spin_unlock_irq(&vga_lock);
 }
 
 static void vga_vesa_unblank(void)
 {
 	/* restore original values of VGA controller registers */
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p(vga_state.CrtMiscIO,video_misc_wr);
 
 	outb_p(0x00,vga_video_port_reg);		/* HorizontalTotal */

@@ -629,7 +630,7 @@
 	/* restore index/control registers */
 	outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
 	outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
-	sti();
+	spin_unlock_irq(&vga_lock);
 }
 
 static void vga_pal_blank(void)

@@ -750,7 +751,7 @@
 		charmap += 4*cmapsz;
 #endif
 
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p( 0x00, seq_port_reg );   /* First, the sequencer */
 	outb_p( 0x01, seq_port_val );   /* Synchronous reset */
 	outb_p( 0x02, seq_port_reg );

@@ -766,7 +767,7 @@
 	outb_p( 0x00, gr_port_val );    /* disable odd-even addressing */
 	outb_p( 0x06, gr_port_reg );
 	outb_p( 0x00, gr_port_val );    /* map start at A000:0000 */
-	sti();
+	spin_unlock_irq(&vga_lock);
 	
 	if (arg) {
 		if (set)

@@ -793,7 +794,7 @@
 		}
 	}
 	
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p( 0x00, seq_port_reg );   /* First, the sequencer */
 	outb_p( 0x01, seq_port_val );   /* Synchronous reset */
 	outb_p( 0x02, seq_port_reg );

@@ -833,8 +834,7 @@
 		inb_p( video_port_status );
 		outb_p ( 0x20, attrib_port );
 	}
-	sti();
-
+	spin_unlock_irq(&vga_lock);
 	return 0;
 }

@@ -865,12 +865,12 @@
 	   registers; they are write-only on EGA, but it appears that they
 	   are all don't care bits on EGA, so I guess it doesn't matter. */
 
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p( 0x07, vga_video_port_reg );		/* CRTC overflow register */
 	ovr = inb_p(vga_video_port_val);
 	outb_p( 0x09, vga_video_port_reg );		/* Font size register */
 	fsr = inb_p(vga_video_port_val);
-	sti();
+	spin_lock_irq(&vga_lock);
 
 	vde = maxscan & 0xff;			/* Vertical display end reg */
 	ovr = (ovr & 0xbd) +			/* Overflow register */

@@ -878,14 +878,14 @@
 	      ((maxscan & 0x200) >> 3);
 	fsr = (fsr & 0xe0) + (fontheight-1);    /*  Font size register */
 
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p( 0x07, vga_video_port_reg );		/* CRTC overflow register */
 	outb_p( ovr, vga_video_port_val );
 	outb_p( 0x09, vga_video_port_reg );		/* Font size */
 	outb_p( fsr, vga_video_port_val );
 	outb_p( 0x12, vga_video_port_reg );		/* Vertical display limit */
 	outb_p( vde, vga_video_port_val );
-	sti();
+	spin_unlock_irq(&vga_lock);	
 
 	vc_resize_all(rows, 0);			/* Adjust console size */
 	return 0;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Keith Owens

2000-11-04 01:39 UTC #19 lore raw

Quoted 6 lines · James Simmons

Quoted 3 lines
* VGA Console can cause SMP deadlock when doing printk {CRITICAL} (Keith Owens)
Still not fixed :-( Here is the patch again. Keith give it a try and tell me if it solves your problems.

The patch looks OK to me. I worked around my original problem (screen deadlock in kdb) by skipping the cli()/restore_flags() when kdb is active, kdb guarantees that only one cpu at a time is doing any work.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[email protected]

author

2000-11-11 21:47 UTC #20 lore raw

Date: Fri, 3 Nov 2000 17:10:52 -0800 (PST)
From: James Simmons <[email protected]>

Quoted 2 lines

* VGA Console can cause SMP deadlock when doing printk {CRITICAL} (Keith Owens)

Still not fixed :-( Here is the patch again. Keith give it a try and tell me if it solves your problems.

Keith, have you had a chance to test the patch? Does it fix things? I note that it's apparently not in test11-pre2.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Christian van Enckevort

2000-11-03 18:36 UTC #21 lore raw

loop device hangs

Quoted 5 lines

10. To Do But Non Showstopper
* Loop device can still hang (William Stearns has script that will hang 2.4.0-test7, Peter Enderborg has a short sequence that will hang 2.4.0test9)

I think I have the same problem with 2.4.0-test10 (with rieserfs-patch). With small images (initrd-ramdisk) I have no problem, but when I prepare an ext2fs-image for a backup on CD, the system will invariably hang. For me this is a showstopper bug. I tried to further investigate this bug. I found it can also be triggered by running bonnie on an ext2fs-image (filesize=200Mb). When it hung, the EIP pointed to somewhere in default_idle. Does anybody have some hints for finding some more useful information about this bug?

Christian van Enckevort
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-03 22:22 UTC #22 lore raw

Quoted 3 lines · [email protected] wrote:

4. Boot Time Failures
* Crashes on boot on some Compaqs ? (may be fixed)

compaq laptops? desktops? or alphas?

Quoted 3 lines

* Various Alpha's don't boot under 2.4.0-test9 (PCI resource allocation problem? Michal Jaegermann; Richard Henderson may have an idea what's failing.)

Elaboration: PCI-PCI bridges are not configured correctly

Quoted 1 line

5. Compile errors

I doubt you need this category :)

Quoted 2 lines

6. In Progress
* Fix all remaining PCI code to use pci_enable_device (mostly done)

Most drivers are done, and all of the important drivers are done (IMHO). Maybe we could move this to a cleanup category? Its definitely not a showstopper..

Quoted 2 lines

* DMFE is not SMP safe (Frank Davis patch exists, but hasn't gotten much commens yet)

update: frank davis patch is poor.

DMFE accesses multiple hardware registers for a single operation, and requires SMP locking to synchronize between all that code.

Quoted 4 lines

* Audit all char and block drivers to ensure they are safe with the 2.3 locking - a lot of them are not especially on the read()/write() path. (Frank Davis --- moving slowly; if someone wants to help, contact Frank)

Haven't heard any update on this in a long while...

Quoted 1 line

* Fixing autofs4 to deal with VFS changes (Jeremy Fitzhardinge)

I thought this was complete a long time ago?

Quoted 4 lines

8. Fix Exists But Isnt Merged
* Many network device drivers don't call MOD_INC_USE_COUNT in dev->open. (Paul Gortmaker has patches)

There exists a patch which makes MOD_xxx in net drivers obsolete. I'm hoping that one will get applied...

Quoted 2 lines

* mtrr.c is broken for machines with >= 4GB of memory (David Wragg has a fix)

His patch looks ok to me, too.... Does somebody want to submit this
patch to Linus? I haven't seen the maintainer (Richard Gooch) speak up on this issue at all.

Quoted 3 lines

* Issue with notifiers that try to deregister themselves? (lnz; notifier locking change by Garzik should backed out, according to Jeff)

Done.

Quoted 2 lines

* The new hot plug PCI interface does not provide a method for passing the correct device name to cardmgr (David Hinds, alan)

Move to "in progress"...

Quoted 2 lines

* 2.4.0-test8 pcmcia is unusable in fall forms (kernel, mixed, or dhinds code) (David Ford)

"fall forms"?

David clearly has problems w/ pcmcia, but it is not at all as broken as he makes it out to be: all my cardbus laptops boot and work.

Quoted 2 lines

* Spin doing ioctls on a down netdeice as it unloads == BOOM (prumpf, Alan Cox)

not an issue.

Quoted 2 lines

Possible other net driver SMP issues (andi
kleen)

No showstoppers AFAICS, but small races do exist.

Quoted 2 lines

* PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is reliable)

Again "whatever". The CardBus code is definitely usable. It is not mature, but saying it is "basically unusable" is wildly inaccurate.

Quoted 5 lines

* RTL 8139 cards sometimes stop responding. Both drivers don't handle this quite good enough yet. (reported by Rogier Wolff, tentatively reported as fixed by David Ford; reports from Frank Jacobberger and Shane Shrybman indicate that it doesn't appear to be fixed in test9)

I'm hoping this is fixed in test10, but haven't gotten any reports back yet...

Quoted 1 line

* kiobuf seperate lock functions/bounce/page_address fixes

Do Stephen Tweedie's recently posted kiobuf patches fix this issue?

Quoted 11 lines

* Potential races in file locking code (Christian Ehrhardt)
+ locks_verify_area checks the wrong range if O_APPEND is set and the current file position is not at the end of the file.
+ dito if the file position changes between the call to locks_verify_area and the actual read/write (requires a shared file pointer, an attacker can use this to circumvent virtually any mandatory lock).
+ active writes should prevent anyone from getting mandatory locks for the area beeing written.
+ active reads should prevent anyone from getting mandatory write locks for the area beeing read.

a fix patch for file locks (related to nfs, but still it appears to fix some general issues) was posted this week:
http://boudicca.tux.org/hypermail/linux-kernel/this-week/0404.html

Quoted 2 lines

* Eepro100 driver can sometimes report out of resources on reboot (Josue Emmanuel Amaro)

More than just on reboot.

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[email protected]

author

2000-11-07 19:36 UTC #23 lore raw

Date: Fri, 03 Nov 2000 17:20:53 -0500
From: Jeff Garzik <[email protected]>

Quoted 3 lines

4. Boot Time Failures
* Crashes on boot on some Compaqs ? (may be fixed)

compaq laptops? desktops? or alphas?

Absolutely no idea. This was one I inherited from Alan's list. If Alan or someone else doesn't speak up on this one, I'll remove it from the list.... (at a guess, it might be the docking station bug that's already been fixed, but without more information I'm only guessing).

Quoted 1 line

* Fixing autofs4 to deal with VFS changes (Jeremy Fitzhardinge)

I thought this was complete a long time ago?

Could be. Jeremy?

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Ford

2000-11-04 02:33 UTC #24 lore raw

Quoted 9 lines · Jeff Garzik

Quoted 2 lines
* 2.4.0-test8 pcmcia is unusable in fall forms (kernel, mixed, or dhinds code) (David Ford)
"fall forms"?
David clearly has problems w/ pcmcia, but it is not at all as broken as he makes it out to be: all my cardbus laptops boot and work.

Quoted 5 lines

Quoted 2 lines
* PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is reliable)
Again "whatever". The CardBus code is definitely usable. It is not mature, but saying it is "basically unusable" is wildly inaccurate.

The qualifiers I reported are not included above so don't take it to mean wide ranging.

I reported pcmcia in all forms was broken for test8 on -my hardware-.

Other kernels such as test10-prex that I'm on now are workable with dhinds pcmcia. I sent you all the requested information you asked for in several forms. The kernel's idea of the the sockets just doesn't work...again, on -my hardware-.

It doesn't matter what voodoo you practice, all of the kernels in the last year have been unable to drive -my hardware- in any sort of stable fashion. Recent kernels just can't figure out IRQs for the sockets.

David's package works in all situations except for the combined ne2k/modem that I reported earlier and the ray_cs in similar fashion.

For the second report, when the kernel did figure out IRQs for the sockets, plugging in a card sometimes killed all software interrupts. I.e. hardware responded such as caps, screen blank/active etc, but no mouse or key events made it past the kernel. Unplugging a card or putting it in socket 0 normally caused a plethura of unending OOPSes or another hang on the insertion.

Ted, please put my qualifier back in, "On this NEC Versa LX laptop", I don't want my reports taken out of context. :)

-d

--
"The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."

[email protected]

author

2000-11-07 19:41 UTC #25 lore raw

Date: Fri, 03 Nov 2000 18:32:31 -0800
From: David Ford <[email protected]>

I reported pcmcia in all forms was broken for test8 on -my hardware-.

Ok, I've refined the PCMCIA comments in the buglist to be more specific. It wasn't clear that anyone besides David Hinds was working on stablizing the 2.4 kernel PCMCIA code, and Linus had already said that he didn't consider it a show-stopper, and that he recommended people use David's external PCMCIA/Cardbus package anyway. So I assumed things had continued to be in a completely broken state, and hadn't bothered to do more digging into what was going on there.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Keith Owens

2000-11-04 10:43 UTC #26 lore raw

Quoted 4 lines · On Fri, 3 Nov 2000 10:09:31 -0500, [email protected] wrote:

9. To Do
* DRM cannot use AGP support module when CONFIG_MODVERSIONS is defined (issue with get_module_symbol caused fix proposed by John Levon to be rejected)

Move this to "in progress" and add MTD code breaks with CONFIG_MODVERSIONS, for the same reason. I wrote a patch to replace get_module_symbol a week ago and sent it to the DRM/AGP/MTD people for testing - no response yet.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Russell King

2000-11-04 20:36 UTC #27 lore raw

Quoted 4 lines · Keith Owens

Move this to "in progress" and add MTD code breaks with CONFIG_MODVERSIONS, for the same reason. I wrote a patch to replace get_module_symbol a week ago and sent it to the DRM/AGP/MTD people for testing - no response yet.

<aol>
I have a fix likewise for the MTD code, so it builds without CONFIG_MODULES </aol>
_____

  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        [email protected]      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-05 23:16 UTC #28 lore raw

In reply to Keith Owens

Quoted 4 lines · Keith Owens

Move this to "in progress" and add MTD code breaks with CONFIG_MODVERSIONS, for the same reason. I wrote a patch to replace get_module_symbol a week ago and sent it to the DRM/AGP/MTD people for testing - no response yet.

Sorry for the delay. I don't actually have any appropriate hardware any more that doesn't now have a JFFS root filesystem, making it difficult to test the modular code :)

Your patch looks like it'll work. Although I don't really see any advantage over {get,put}_module_symbol() in this case, it does look like it can be used to finally provide module persistent storage, which will be useful.

However, the easy fix for the MTD code is to use EXPORT_SYMBOL_NOVERS() for the offending symbols. It's the most appropriate for putting into 2.4.

If the inter_module_{put,get} change is really going into 2.4 at this late stage, then I'll merge your patch into my CVS tree and look at updating the MTD code in the 2.4 tree to a more recent version. I was intending to leave that for later, though.

Also - if it goes into 2.4, please make sure it goes into 2.2 as well. get_module_symbol() is already broken there because it doesn't increase the module's use count, and it'll prevent an ugly mess of ifdefs.

Signature · 7 lines

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Keith Owens

2000-11-06 00:48 UTC #29 lore raw

Quoted 4 lines · David Woodhouse

Your patch looks like it'll work. Although I don't really see any advantage over {get,put}_module_symbol() in this case, it does look like it can be used to finally provide module persistent storage, which will be useful.

Cleanliness. All other module data flows go via explicit symbols which are fixed up at link time or via registration functions. Having a few sources that use a third mechanism which forces people to use EXPORT_SYMBOL_NOVERS() to make it work is messy and redundant.

I'm not sure why you think this can be used for module persistent storage. If a module calls inter_module_register() on load, it should call inter_module_unregister() on unload. All the registered data points into the loaded module, remove the module and the storage disappears as well.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 00:55 UTC #30 lore raw

Quoted 5 lines · Keith Owens

I'm not sure why you think this can be used for module persistent storage. If a module calls inter_module_register() on load, it should call inter_module_unregister() on unload. All the registered data points into the loaded module, remove the module and the storage disappears as well.

You can kmalloc() both the im_name and userdata arguments to inter_module_register and you ought to be able to pass NULL as the owner.

Signature · 7 lines

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Keith Owens

2000-11-06 01:29 UTC #31 lore raw

Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 10 lines · David Woodhouse

Quoted 5 lines · Keith Owens
I'm not sure why you think this can be used for module persistent storage. If a module calls inter_module_register() on load, it should call inter_module_unregister() on unload. All the registered data points into the loaded module, remove the module and the storage disappears as well.
You can kmalloc() both the im_name and userdata arguments to inter_module_register and you ought to be able to pass NULL as the owner.

Ughh! That is definitely abusing the inter_module functions. If we need persistent module storage then we should add a clean interface to do it instead of using kmalloc and overloading inter_module_xxx.

What do people think, do we need module persistent storage? There are already entries in struct module for persistent data but there is no way of setting those fields, nor is there any code in modutils to handle persistent storage. This will probably be a 2.5 change but I want to get an idea of the requirements before coding anything.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 06:40 UTC #32 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 10 lines · Keith Owens

Quoted 8 lines · David Woodhouse
Quoted 5 lines · Keith Owens
I'm not sure why you think this can be used for module persistent storage. If a module calls inter_module_register() on load, it should call inter_module_unregister() on unload. All the registered data points into the loaded module, remove the module and the storage disappears as well.

Quoted 6 lines

Quoted 2 lines
You can kmalloc() both the im_name and userdata arguments to inter_module_register and you ought to be able to pass NULL as the owner.
Ughh! That is definitely abusing the inter_module functions. If we need persistent module storage then we should add a clean interface to do it instead of using kmalloc and overloading inter_module_xxx.

Why? It's got to get kmalloc'd anyway, and code reuse is _good_. Experiment with different names for inter_module_xxx until you feel happier :)

Quoted 1 line

What do people think, do we need module persistent storage?

The primary reason that I've often lamented its removal is for auto-loaded sound drivers to store their mixer level on unload, in order to reset to the same values upon being reloaded.

Quoted 2 lines

This will probably be a 2.5 change but I want to get an idea of the requirements before coding anything.

Strictly speaking, all the inter_module_xxx stuff should probably wait for 2.5.

Signature · 7 lines

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Oliver Xymoron

2000-11-06 07:13 UTC #33 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to Keith Owens

Quoted 1 line · Keith Owens

What do people think, do we need module persistent storage?

Hopefully not. The standard examples (mixer levels, etc) are better handled with a userspace tool hooked by modprobe. This even gets persistence across reboots if that's what's wanted.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 07:18 UTC #34 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 3 lines · Oliver Xymoron

Hopefully not. The standard examples (mixer levels, etc) are better handled with a userspace tool hooked by modprobe. This even gets persistence across reboots if that's what's wanted.

Implement a way for a userspace tool to get the correct mixer levels in place at the time the sound hardware is reset, so there are no glitches in the levels, and I'll agree with you.

Signature · 7 lines

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 07:26 UTC #35 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 10 lines · David Woodhouse

Quoted 3 lines · Oliver Xymoron
Hopefully not. The standard examples (mixer levels, etc) are better handled with a userspace tool hooked by modprobe. This even gets persistence across reboots if that's what's wanted.
Implement a way for a userspace tool to get the correct mixer levels in place at the time the sound hardware is reset, so there are no glitches in the levels, and I'll agree with you.

Linux-Mandrake's initscripts run aumix on bootup and shutdown, to take care of this...

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 07:29 UTC #36 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 2 lines · Jeff Garzik

Linux-Mandrake's initscripts run aumix on bootup and shutdown, to take care of this...

So does Red Hat. You can also have a post-install script which does it after a module is auto-loaded. There can still be a number of seconds between the initialisation of the hardware and the desired mixer levels actually getting set.

Signature · 7 lines

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 10:55 UTC #37 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 6 lines

Quoted 3 lines
Implement a way for a userspace tool to get the correct mixer levels in place at the time the sound hardware is reset, so there are no glitches in the levels, and I'll agree with you.
Linux-Mandrake's initscripts run aumix on bootup and shutdown, to take care of this...

And they don't solve the problem David was talking about. There is a short deeply unpleasant scream from some soundcards on reload because the card init and the 0.5-1 second later aumix run dont stop the feedback loop fast enough when a mic is plugged in

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Dan Hollis

2000-11-06 11:06 UTC #38 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines · Alan Cox

And they don't solve the problem David was talking about. There is a short deeply unpleasant scream from some soundcards on reload because the card init and the 0.5-1 second later aumix run dont stop the feedback loop fast enough when a mic is plugged in

This is why alsa starts up all devices totally muted. Maybe its time for David to move to alsa ;)

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 11:05 UTC #39 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 9 lines · Dan Hollis

Quoted 4 lines · Alan Cox
And they don't solve the problem David was talking about. There is a short deeply unpleasant scream from some soundcards on reload because the card init and the 0.5-1 second later aumix run dont stop the feedback loop fast enough when a mic is plugged in
This is why alsa starts up all devices totally muted. Maybe its time for David to move to alsa ;)

I wouldn't mind leaving devices totally muted until open()...

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 11:37 UTC #40 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines

Quoted 2 lines
This is why alsa starts up all devices totally muted. Maybe its time for David to move to alsa ;)
I wouldn't mind leaving devices totally muted until open()...

You need to leave the mixer for cd, tv and radio pass through -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 11:38 UTC #41 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 7 lines · Alan Cox

Quoted 5 lines
Quoted 3 lines
This is why alsa starts up all devices totally muted. Maybe its time for David to move to alsa ;)
I wouldn't mind leaving devices totally muted until open()...
You need to leave the mixer for cd, tv and radio pass through

Good point. Also might need to flush default settings to the mixer, if you start playing w/out first setting the mixer to anything...

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 11:08 UTC #42 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to Dan Hollis

Quoted 2 lines · [email protected] said:

This is why alsa starts up all devices totally muted. Maybe its time
for David to move to alsa ;)

Muted is not what I want either, although that's fine when the module is _first_ loaded after booting.

What I want is for the mixer settings not to change at all, when the module is auto-unloaded and later auto-loaded again. I may have set them to pass through the line input.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 11:10 UTC #43 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to Dan Hollis

Quoted 11 lines · David Woodhouse

Quoted 2 lines · [email protected] said:
This is why alsa starts up all devices totally muted. Maybe its time
for David to move to alsa ;)
Muted is not what I want either, although that's fine when the module is _first_ loaded after booting.
What I want is for the mixer settings not to change at all, when the module is auto-unloaded and later auto-loaded again. I may have set them to pass through the line input.

The API allows for setup activity to occur on the fd before sound is actually started, mixer setup can be one of those steps...

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 11:23 UTC #44 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to Dan Hollis

Remember the /dev/mixer and /dev/dsp are separate.

* Driver initializes mixer to 100% muted
* Userspace app sets desired values to /dev/mixer
* Userspace app opens /dev/dsp to play sound

I don't see where any sound can "escape" in this scenario, and it doesn't require any module data persistence...

Jeff

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 11:38 UTC #45 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 5 lines · [email protected] said:

* Driver initializes mixer to 100% muted * Userspace app sets desired
values to /dev/mixer * Userspace app opens /dev/dsp to play sound
I don't see where any sound can "escape" in this scenario, and it doesn't require any module data persistence...

* User boots kernel
* User loads mixer app
* Sound module is autoloaded, defaults to zero levels. This is fine.
* User sets 'line in' level to appropriate level to listen to radio
* User closes mixer app
* Time passes
* Sound module is unloaded
* User continues to happily listen to radio through sound card
* Time passes
* User is listening intently to something on the radio
* Something wants to beep through /dev/audio
* Sound module is autoloaded again, default to zero levels. This time it is _NOT_ fine. User is rightly pissed off :)

It's fine to default to zero levels the first time the sound module is loaded after booting. Not on subsequent reloads though.

A long time ago, I made the sb16 driver use the persistent storage facility of kerneld to store mixer levels. I was happy with this right up until kerneld disappeared :)

I then made a version which read the current mixer levels back from the hardware on initialisation, and didn't reset them. That didn't work on all sb16 hardware, but it worked for me (tm).

Persistent storage is the best way to do it though. It doesn't have to be persistent over reboots, just during the lifetime of the kernel.

The inter_module_xxx() stuff would facilitate this quite nicely.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Paul Jakma

2000-11-06 18:22 UTC #46 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 1 line · David Woodhouse

* Sound module is autoloaded again, default to zero levels.

so you use the 'post-install' option of modules.conf to run your mixer-level setting script.

Quoted 2 lines

This time it is _NOT_ fine. User is rightly pissed off :)

even better: is there any pressing need for /all/ modules to be auto-unloaded? things like sound modules should be statically loaded at boot time and never removed for 99% of workstations i think.

i'd also like to see dist's adopt a nice config file specifying which modules to statically load at boot-time. (i know i want i them loaded). then maybe info from depmod could be applied to remove redundant loads.

Quoted 2 lines

The inter_module_xxx() stuff would facilitate this quite nicely.

but if userspace can do it just as easily... (in the case of sound modules anyway)

Quoted 2 lines

--
dwmw2

--paulj

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 21:20 UTC #47 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines

i'd also like to see dist's adopt a nice config file specifying which modules to statically load at boot-time. (i know i want i them loaded). then maybe info from depmod could be applied to remove redundant loads.

Its called modules.conf. It has all these nice preload directives in it

Quoted 1 line

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Paul Jakma

2000-11-06 22:59 UTC #48 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 1 line · Alan Cox

Its called modules.conf. It has all these nice preload directives in it

cool..

doesn't seem to be documented though in modutils 2.3.17. what exactly does it do?

regards,

Signature · 12 lines

Paul Jakma	[email protected]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
I finally went to the eye doctor.  I got contacts.  I only need them to
read, so I got flip-ups.
		-- Steven Wright

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Keith Owens

2000-11-07 02:12 UTC #49 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 7 lines · Paul Jakma

Quoted 1 line · Alan Cox
Its called modules.conf. It has all these nice preload directives in it
cool..
doesn't seem to be documented though in modutils 2.3.17. what exactly does it do?

man modules.conf (yes, it _is_ documented).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 11:42 UTC #50 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 2 lines · David Woodhouse

* Sound module is unloaded
* User continues to happily listen to radio through sound card

You're using the sound card without a driver?

Quoted 5 lines

* Time passes
* User is listening intently to something on the radio
* Something wants to beep through /dev/audio
* Sound module is autoloaded again, default to zero levels. This time it is _NOT_ fine. User is rightly pissed off :)

If you create a post-action in /etc/modules.conf which initializes the mixer to proper levels, this problem does not exist.

No kernel coding required.

Jeff

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 11:48 UTC #51 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 2 lines · [email protected] said:

Quoted 1 line
* User continues to happily listen to radio through sound card
You're using the sound card without a driver?

Yes. The sound card allows itself to be unloaded when the pass-through mixer levels are non-zero. This is reasonable iff it can be reloaded without destroying those levels again.

Quoted 2 lines · [email protected] said:

If you create a post-action in /etc/modules.conf which initializes
the mixer to proper levels, this problem does not exist.

Yes it does. It can be a few seconds between initialisation and the post-action running. That's plenty of time to miss what the news announcer was saying about whether you need to go to work today (my gf is a teacher) or to wake the entire house if the mixer levels don't default to zero.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 12:00 UTC #52 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 8 lines · David Woodhouse

Quoted 2 lines · [email protected] said:
Quoted 1 line
* User continues to happily listen to radio through sound card
You're using the sound card without a driver?
Yes. The sound card allows itself to be unloaded when the pass-through mixer levels are non-zero. This is reasonable iff it can be reloaded without destroying those levels again.

I don't think that is reasonable.

The first thing most drivers do is reset the hardware. That inevitably
leads to some sort of blip, when it comes to sound drivers. If you -don't- reset the hardware, the driver is using hardware that is in an unknown state. (using hardware w/out resetting it == unknown state)

You are depending on the hardware to keep its state -between- driver unload and driver reload. That seems inherently unstable to me. It amazes me that such is supported.

Jeff

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 12:05 UTC #53 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 1 line

I don't think that is reasonable.

I think its totally reasonable.

Quoted 1 line

The first thing most drivers do is reset the hardware. That inevitably

Because there is no persistent storage to remember the fact the hardware is running.

Quoted 3 lines

You are depending on the hardware to keep its state -between- driver unload and driver reload. That seems inherently unstable to me. It amazes me that such is supported.

Well if you want to rewrite the entire module handling and locking so that mixer levels determine the load/unload behaviour according to AC97 register combinations and then train users to mute all their inputs before using rmmod go ahead 8)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 13:13 UTC #54 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines · [email protected] said:

Quoted 2 lines
The sound card allows itself to be unloaded when the pass-through mixer levels are non-zero. This is reasonable iff ...
I don't think that is reasonable.

You don't think that it's reasonable for the sound card to allow itself to be unloaded when the pass-through mixer levels are non-zero?

So you're suggesting that we should prevent the sound drivers from being unloaded at all in that situation?

That would also solve the problem, at the cost of still keeping the sound module in unpagable RAM all the time.

Quoted 2 lines · [email protected] said:

The first thing most drivers do is reset the hardware. That
inevitably leads to some sort of blip, when it comes to sound drivers.

A _momentary_ blip on certain hardware is acceptable if it's unavoidable. Changing the levels and leaving them wrong for seconds before a user-space post-install script fixes them is not acceptable.

Quoted 2 lines · [email protected] said:

You are depending on the hardware to keep its state -between- driver unload and driver reload. That seems inherently unstable to me.

No we're not. After the kerneld code was removed, I hacked up something to do that, but it was a suboptimal solution and wasn't reliable on all hardware. As I said, persistent storage is the better solution.

With persistent storage, the sound driver is free to reset and initialise the sound card hardware upon reload - it's just that it can initialise it to the levels which the user had previously set, rather than to the compiled-in default levels (which are preferably zero).

Initialising the levels to a default and expecting a user-space app to fix it later is not good enough.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 13:22 UTC #55 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

I think we're getting confused. What I'm advocating is something like this:

init_module()

{
	struct mixer_levels *levels;

	levels = inter_module_get("mysoundcard_mixerlevels");

	if (!levels)
		/* We haven't been loaded before. Default to zero */
		levels = &default_levels;

	init_hardware(levels);
}

cleanup_module()

{
	struct mixer_levels *levels = kmalloc(sizeof *levels);

	if (levels) {
		/* Record current the levels so we can init the hardware
		   to the same next time we're loaded */
		memcpy(levels, current_levels, sizeof(*levels));
		inter_module_register("mysoundcard_mixerlevels", levels);
	}
}

(Note it's pseudocode. I _know_ it doesn't compile and that the name we pass to inter_module_register is removed when the module is unloaded. Oh and that inter_module_register will panic() and kill the whole system on the second unload because a registration with that name already exists.)

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 13:40 UTC #56 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 5 lines · David Woodhouse

Quoted 2 lines · [email protected] said:
Quoted 2 lines
The sound card allows itself to be unloaded when the pass-through mixer levels are non-zero. This is reasonable iff ...

Quoted 7 lines

Quoted 1 line
I don't think that is reasonable.
You don't think that it's reasonable for the sound card to allow itself to be unloaded when the pass-through mixer levels are non-zero?
So you're suggesting that we should prevent the sound drivers from being unloaded at all in that situation?

I am thinking about the bigger picture: You are unloading a driver, then continuing to use the hardware. To me, that is an undefined state.

Quoted 2 lines

That would also solve the problem, at the cost of still keeping the sound module in unpagable RAM all the time.

Oh, the horror!

[jgarzik@rum linux_2_4]$ ls -l drivers/sound/via82cxxx_audio.o
-rw-r--r-- 1 jgarzik jgarzik 27968 Nov 6 03:28
drivers/sound/via82cxxx_audio.o

So you would rather load everybody's kernel down with mixer level / module persistence gunk... than simply load a kernel module at boot, and leave it alone?

Quoted 7 lines

With persistent storage, the sound driver is free to reset and initialise the sound card hardware upon reload - it's just that it can initialise it to the levels which the user had previously set, rather than to the compiled-in default levels (which are preferably zero).
Initialising the levels to a default and expecting a user-space app to fix it later is not good enough.

The one thing that you and I agree on: It would be nice if the driver did not init the mixer to a set of defaults, when a preferred set is available.

However, since simply leaving the driver loaded solves all this mess, it doesn't seem worth changing drivers to do anything different.

Jeff

Signature · 8 lines

Jeff Garzik             | "When I do this, my computer freezes."
Building 1024           |          -user
MandrakeSoft            | "Don't do that."
                        |          -level 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 13:57 UTC #57 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 3 lines · [email protected] said:

I am thinking about the bigger picture: You are unloading a driver,
then continuing to use the hardware. To me, that is an undefined state.

We're only using the pass-through levels. It's undefined but it doesn't matter to the software. I'd actually suggest that for hardware which does stop the pass-through audio when the driver is unloaded, we really ought not unload the driver while those levels are non-zero.

We should still reset the hardware completely when we reload the driver - it's just that we should reset it to the levels previously set by the user, rather than resetting it to zeroes.

Quoted 2 lines · [email protected] said:

However, since simply leaving the driver loaded solves all this mess,
it doesn't seem worth changing drivers to do anything different.

Leaving the driver loaded has been my solution ever since kerneld was taken out. I merely commented that Keith's new stuff would allow me to get persistent storage working again. It's not very difficult to change the driver to use it.

I believe the SBLive! driver is a little larger than the example you pasted. I think we probably do care about adding a little bit more to the pool of permanently unswappable pages here and there.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-06 13:38 UTC #58 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 8 lines · David Woodhouse

Quoted 2 lines · [email protected] said:
Quoted 1 line
* User continues to happily listen to radio through sound card
You're using the sound card without a driver?
Yes. The sound card allows itself to be unloaded when the pass-through mixer levels are non-zero. This is reasonable iff it can be reloaded without destroying those levels again.

Quoted 8 lines

Quoted 2 lines · [email protected] said:
If you create a post-action in /etc/modules.conf which initializes
the mixer to proper levels, this problem does not exist.
Yes it does. It can be a few seconds between initialisation and the post-action running. That's plenty of time to miss what the news announcer was saying about whether you need to go to work today (my gf is a teacher) or to wake the entire house if the mixer levels don't default to zero.

So autoload the module with a "dont_screw_with_mixer" option. When the kernel first boots, initialise the mixer to suitable settings (load the module with "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change the mixer settings on load.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 13:41 UTC #59 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines · [email protected] said:

So autoload the module with a "dont_screw_with_mixer" option. When
the kernel first boots, initialise the mixer to suitable settings (load the module with "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change the mixer settings on load.

Not reliable. You can't read back the current mixer state from all hardware, even if you _are_ willing to assume that it has remained in a sensible state while the driver has been unloaded.

The driver needs to reset the card to the desired levels.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-06 15:25 UTC #60 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 9 lines · David Woodhouse

Quoted 4 lines · [email protected] said:
So autoload the module with a "dont_screw_with_mixer" option. When
the kernel first boots, initialise the mixer to suitable settings (load the module with "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change the mixer settings on load.
Not reliable. You can't read back the current mixer state from all hardware, even if you _are_ willing to assume that it has remained in a sensible state while the driver has been unloaded.

Irrelevant. The current mixer settings don't matter: what matters is that the driver does not change them.

Quoted 1 line

The driver needs to reset the card to the desired levels.

What desired levels? The only desired levels are the current ones, which the driver does not and (sometimes) cannot know. Leave well alone.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 15:35 UTC #61 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 2 lines · [email protected] said:

Irrelevant. The current mixer settings don't matter: what matters is
that the driver does not change them.

It does matter. The sound driver needs to be able to _read_ the current levels. Almost all mixer programs will start by doing this, to set the slider to the correct place.

Quoted 5 lines

Quoted 1 line
The driver needs to reset the card to the desired levels.
What desired levels? The only desired levels are the current ones, which the driver does not and (sometimes) cannot know. Leave well alone.

It does not know them. Correct. But with persistent module storage, it _could_ know them. It cannot know them the _first_ time the module is loaded after booting. That's fine. On subsequent loads, it can and should DTRT.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Horst von Brand

2000-11-06 16:34 UTC #62 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 7 lines · David Woodhouse

Quoted 2 lines · [email protected] said:
Irrelevant. The current mixer settings don't matter: what matters is
that the driver does not change them.
It does matter. The sound driver needs to be able to _read_ the current levels. Almost all mixer programs will start by doing this, to set the slider to the correct place.

OK, how then using _2_ modules, data and worker:

- Data (containing the mixer levels or whatever other data you want to save) can only be unloaded after resetting to some default state. When loading it sets the default state.
- Worker does the work, and on loading loads the data one (if not yet resident) [This is automatic as the worker depends on symbols the data module exports].

No funny "persistent data" mechanisms or screwups when the worker gets removed and reinserted. In many cases the data module could be shared among several others, in other cases it would have to be able lo load several times or manage several incarnations of its payload.

Sure, makes sense only if the worker module is largeish; if not, just let it stay put (When reconfiguring anything, increment module use count; decrement on reset. This should do the trick also for the data module above).

Signature · 8 lines

Dr. Horst H. von Brand                       mailto:[email protected]
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 17:08 UTC #63 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines · [email protected] said:

No funny "persistent data" mechanisms or screwups when the worker
gets removed and reinserted. In many cases the data module could be shared among several others, in other cases it would have to be able lo load several times or manage several incarnations of its payload.

The reason I brought this up now is because Keith's new inter_module_register stuff could easily be used to provide this functionality _without_ the extra module remaining loaded.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Horst von Brand

2000-11-07 01:27 UTC #64 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 9 lines · David Woodhouse

Quoted 4 lines · [email protected] said:
No funny "persistent data" mechanisms or screwups when the worker
gets removed and reinserted. In many cases the data module could be shared among several others, in other cases it would have to be able lo load several times or manage several incarnations of its payload.
The reason I brought this up now is because Keith's new inter_module_register stuff could easily be used to provide this functionality _without_ the extra module remaining loaded.

AFAIU, this is a acknowledged wart, to be added if there is no sane way out. Better just loose it before it gets into the kernel, no?

Signature · 7 lines

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Martin Dalecki

2000-11-06 17:09 UTC #65 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 11 lines · Horst von Brand

Quoted 7 lines · David Woodhouse
Quoted 2 lines · [email protected] said:
Irrelevant. The current mixer settings don't matter: what matters is
that the driver does not change them.
It does matter. The sound driver needs to be able to _read_ the current levels. Almost all mixer programs will start by doing this, to set the slider to the correct place.
OK, how then using _2_ modules, data and worker:

People that's all designing for the sake of design.
And it's trying to solve a non existant problem:
Just load the damn module once and leave it there where it is. Drivers are supposed to handle present hardware - if the hardware is there - there should be a driver handling it as well.
The argument for saving some memmory is nonapplicable becouse in the case of expected usage in the future you have anyway to assume that in this futere there will be sufficient memmory for it there. And then please remember that all possible space savings are in the granularity of
pages!

Could some one add this to the FAQ ... please!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 17:29 UTC #66 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 2 lines

Drivers are supposed to handle present hardware - if the hardware is there - there should be a driver handling it as well.

Thats not how things have worked historically. Thats not consistent with other modules either.

Quoted 3 lines

The argument for saving some memmory is nonapplicable becouse in the case of expected usage in the future you have anyway to assume that in this futere there will be sufficient memmory for it there. And then

Rubbish

Quoted 1 line

Could some one add this to the FAQ ... please!

You got the letters in the wrong order. Your proposal is at best a Frequently Questioned Answer

Quoted 1 line

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alon Ziv

2000-11-06 17:23 UTC #67 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

The best solution to the sound driver issue, IMHO, is still entirely userspace---
just no-one has written it yet.
What we should do:
1. Before auto-unload of the driver, run a small utility which will read mixer settings
and save them somewhere
2. When auto-loading the driver, use driver arguments which are initialized from the
settings saved above
All that's missing is the method of passing data from step 1 to step 2.

----- Original Message -----
From: "David Woodhouse" <[email protected]>
To: "Horst von Brand" <[email protected]>
Cc: <[email protected]>
Sent: Monday, November 06, 2000 19:06
Subject: Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 12 lines

Quoted 4 lines · [email protected] said:
No funny "persistent data" mechanisms or screwups when the worker
gets removed and reinserted. In many cases the data module could be shared among several others, in other cases it would have to be able lo load several times or manage several incarnations of its payload.
The reason I brought this up now is because Keith's new inter_module_register stuff could easily be used to provide this functionality _without_ the extra module remaining loaded.

Quoted 9 lines

--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 17:25 UTC #68 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 7 lines · [email protected] said:

The best solution to the sound driver issue, IMHO, is still entirely userspace--- just no-one has written it yet. What we should do: 1. Before auto-unload of the driver, run a small utility which will read mixer settings
and save them somewhere 2. When auto-loading the driver, use driver
arguments which are initialized from the
settings saved above

That could work, although it may be better to make it more generic and capable of handling any form of data.

Any form of persistent storage would do - and if it can be handled entirely in userspace, all the better. I merely pointed out that Keith's inter_module_xxx could provide this quite cleanly. Others disputed that it was required at all.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 17:34 UTC #69 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to Alon Ziv

Quoted 7 lines

1. Before auto-unload of the driver, run a small utility which will read mixer settings
and save them somewhere
2. When auto-loading the driver, use driver arguments which are initialized from the
settings saved above
All that's missing is the method of passing data from step 1 to step 2.

A simple more generic solution is to do this

struct things_to_keep my_bits

{
	..
};

struct things_to_keep __persistent card_info[NUM_CARDS] {
}

and have insmod do

load module up
open /var/run/moduledata/$modname
if exists && is from this boot then && is right size
read data into __persistent ELF section
endif
load into kernel
init module

and rmmod
cleanup module
open /var/run/moduledata/$modname write data from __persistent segment into file

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Rogier Wolff

2000-11-06 19:50 UTC #70 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 1 line · Alan Cox

A simple more generic solution is to do this

[....]

Quoted 3 lines

	if exists && is from this boot then && is right size
		read data into __persistent ELF section
	endif

Alan, why are you stating "if it's from this boot"? I can think that maybe you want to keep stuff across boots too. Maybe once we're at it, have two sections. One that is persistent across boots, the other isn't.

Roger.

Signature · 8 lines

** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
*       Common sense is the collection of                                *
******  prejudices acquired by age eighteen.   -- Albert Einstein ********
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 21:34 UTC #71 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 8 lines

Quoted 3 lines
	if exists && is from this boot then && is right size
		read data into __persistent ELF section
	endif
Alan, why are you stating "if it's from this boot"? I can think that maybe you want to keep stuff across boots too. Maybe once we're at it, have two sections. One that is persistent across boots, the other isn't.

Possibly. The cases brought up so far are all 'within one boot'. But I agree you could add long term persistent data if there was a need

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Tim Riker

2000-11-06 19:34 UTC #72 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to Alon Ziv

Could we handle this by setting a nomixerreset=1 option in modules.conf or as the module default that would effect module reloads. Then on boot up explicitly modprobe with a mixerlevel=0 and then set the levels via aumix etc?

This way the existing hardware can keep the levels if it knows how. As mentioned there would also have to be a setlevels user script called after suspend/resume.

Barring this, we could create a persistantdata module that we can modprobe and then discover with Keith's inter_module_xxx and read/write opaque data to/from. Then if the user does not want to use it they can just "alias persistantdata off" it and poof.

Quoted 25 lines · David Woodhouse

Quoted 7 lines · [email protected] said:
The best solution to the sound driver issue, IMHO, is still entirely userspace--- just no-one has written it yet. What we should do: 1. Before auto-unload of the driver, run a small utility which will read mixer settings
and save them somewhere 2. When auto-loading the driver, use driver
arguments which are initialized from the
settings saved above
That could work, although it may be better to make it more generic and capable of handling any form of data.
Any form of persistent storage would do - and if it can be handled entirely in userspace, all the better. I merely pointed out that Keith's inter_module_xxx could provide this quite cleanly. Others disputed that it was required at all.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Signature · 7 lines

Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 21:33 UTC #73 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines

Barring this, we could create a persistantdata module that we can modprobe and then discover with Keith's inter_module_xxx and read/write opaque data to/from. Then if the user does not want to use it they can just "alias persistantdata off" it and poof.

All of this is kernel code we don't need. Its not a good solution generically or otherwise. Modutils should just use the persistent data stuff that has hooks ready to roll already.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 17:23 UTC #74 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines

No funny "persistent data" mechanisms or screwups when the worker gets removed and reinserted. In many cases the data module could be shared among several others, in other cases it would have to be able lo load several times or manage several incarnations of its payload.

It actually seems the persistent data mechanism in user space wouldnt be much different in implementation.

Add a 'preserved' tag for one section of module memory. On load look up the data, if its from this boot memcpy it into the module. On unload write it back to disk. No kernel code needed.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jamie Lokier

2000-11-08 14:56 UTC #75 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 3 lines · Alan Cox

Add a 'preserved' tag for one section of module memory. On load look up the data, if its from this boot memcpy it into the module. On unload write it back to disk. No kernel code needed.

I like! No kernel code, yet no races or delay.

As written that removes the possibilities of variable length persistant data, and the data is opaque to user space.

MODULE_PARM provides type information and structure to the data. Why not mark certain PARMS as persistent? Not all would be named -- a block of opaque data is useful. But certain things like all the mixer levels could be named parameters, giving you both persistant storage _and_ explicit configuration when you want that. "s" PARMS (or similar) can hold variable length data.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-06 16:47 UTC #76 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to David Woodhouse

Quoted 6 lines · David Woodhouse

Quoted 2 lines · [email protected] said:
Irrelevant. The current mixer settings don't matter: what matters is
that the driver does not change them.
It does matter. The sound driver needs to be able to _read_ the current levels.

So do so. That's a hardware/driver issue. If the hardware is broken, put a workaround in the driver for that hardware (make the driver persistent, as Horst suggested, perhaps). Don't kludge the kernel to mask hardware bugs.

Quoted 2 lines

Almost all mixer programs will start by doing this, to set the slider to the correct place.

Yippee. As we all know, implementing GUI volume controls and putting the slider in the right place is a kernel function, and nothing to do with userspace...

If you want your volume control applet to be able to read the current volume settings, even on buggy hardware which can't really do that, put the kludge in userspace. Or if you really want, put it in your driver for buggy hardware, in the way Horst suggested.

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
The driver needs to reset the card to the desired levels.
What desired levels? The only desired levels are the current ones, which the driver does not and (sometimes) cannot know. Leave well alone.
It does not know them. Correct. But with persistent module storage, it _could_ know them.

No it cannot. The desired levels have not been defined: there are no desired levels to determine! Don't tamper with settings you don't need to.

Quoted 3 lines

It cannot know them the _first_ time the module is loaded after booting. That's fine. On subsequent loads, it can and should DTRT.

The right thing in this context is not to screw with hardware settings unless and until it is given settings to set. Do not set values arbitrarily:
set only the values you are explicitly given. Anything else is simply a bug in your driver.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Horst von Brand

2000-11-06 16:59 UTC #77 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

[Chopped down Cc: list]

Quoted 1 line · James A. Sutherland

On Mon, 06 Nov 2000, David Woodhouse wrote:

[...]

Quoted 6 lines

Quoted 2 lines
It does not know them. Correct. But with persistent module storage, it _could_ know them.
No it cannot. The desired levels have not been defined: there are no desired levels to determine! Don't tamper with settings you don't need to.

The problem (AFAIU) is that if the levels aren't set on startup, they are random in some cases. So you'd have to save (at least) the fact that they have been initalized. Just that would be easy: Set aside a word in the kernel, which is set to 0 when booting, and which then gets the value 1 when the hardware is initialized. For more fancy stuff, splitting the module into data/code (as I suggested) should do the trick with minimal impact on the rest.

Signature · 8 lines

Dr. Horst H. von Brand                       mailto:[email protected]
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-06 17:05 UTC #78 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 9 lines · Horst von Brand

[Chopped down Cc: list]
Quoted 1 line · James A. Sutherland
On Mon, 06 Nov 2000, David Woodhouse wrote:
[...]
Quoted 2 lines
Quoted 2 lines
It does not know them. Correct. But with persistent module storage, it _could_ know them.

Quoted 6 lines

Quoted 3 lines
No it cannot. The desired levels have not been defined: there are no desired levels to determine! Don't tamper with settings you don't need to.
The problem (AFAIU) is that if the levels aren't set on startup, they are random in some cases.

So set them on startup. NOT when the driver is first loaded. Put it in the rc.d scripts.

Quoted 2 lines

So you'd have to save (at least) the fact that they have been initalized.

No, you don't.

Quoted 3 lines

Just that would be easy: Set aside a word in the
kernel, which is set to 0 when booting, and which then gets the value 1 when the hardware is initialized.

Why bother? Just set the settings *explicitly* on boot, rather than in the driver itself.

Quoted 3 lines

For more fancy stuff, splitting the
module into data/code (as I suggested) should do the trick with minimal impact on the rest.

No need. Let userspace save it somewhere, if that's needed.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 17:13 UTC #79 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 2 lines · [email protected] said:

So set them on startup. NOT when the driver is first loaded. Put it
in the rc.d scripts.

No. You should initialise the hardware completely when the driver is reloaded. Although the expected case is that the levels just happen to be the same as the last time the module was loaded, you can't know that the machine hasn't been suspended and resumed since then.

Quoted 1 line · [email protected] said:

No need. Let userspace save it somewhere, if that's needed.

Don't troll, James. Reread the thread and see why doing it in userspace is too late.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Paul Jakma

2000-11-06 18:38 UTC #80 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 2 lines · David Woodhouse

No. You should initialise the hardware completely when the driver is reloaded.

and it is. just that 'mixer levels' are subjective - different users have different tastes. in what way does:

- init to mute
- user set to liking

fail people?

(sound modules shouldn't be unloaded as a matter of course, and user set can be done with post-install option of modules.conf)

Quoted 3 lines

the same as the last time the module was loaded, you can't know that the machine hasn't been suspended and resumed since then.

reloading modules may be a neccessary hack at present to reinit the drivers after suspend/resume, but surely the correct answer there is to go fix power management. the modules are not unloaded by the kernel as part of the suspend event and they are not loaded as part of the resume event. the module persists across the power event, so if something breaks, go fix the power management handling - the driver doesn't handle it properly!

--paulj

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Horst von Brand

2000-11-07 01:27 UTC #81 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

David Woodhouse <[email protected]> said:

[...]

Quoted 4 lines

No. You should initialise the hardware completely when the driver is reloaded. Although the expected case is that the levels just happen to be the same as the last time the module was loaded, you can't know that the machine hasn't been suspended and resumed since then.

Oh? Suspending with the module loaded is forbidden then?

Signature · 6 lines

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-06 17:49 UTC #82 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 8 lines · David Woodhouse

Quoted 2 lines · [email protected] said:
So set them on startup. NOT when the driver is first loaded. Put it
in the rc.d scripts.
No. You should initialise the hardware completely when the driver is reloaded. Although the expected case is that the levels just happen to be the same as the last time the module was loaded, you can't know that the machine hasn't been suspended and resumed since then.

If suspend/resume changes the settings of the card, you need to deal with that as a separate issue - otherwise resume isn't restoring things properly. Perhaps you need to prevent module unloading. Just restoring the correct settings when the driver is loaded is definitely too late.

Quoted 5 lines

Quoted 1 line · [email protected] said:
No need. Let userspace save it somewhere, if that's needed.
Don't troll, James. Reread the thread and see why doing it in userspace is too late.

Why is it too late? There is no need for the driver to set *any* volume levels on load. When told to load the driver, just LOAD the DRIVER. Don't reset the card, or make ANY changes.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Horst von Brand

2000-11-07 01:27 UTC #83 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 1 line · James A. Sutherland

On Mon, 06 Nov 2000, Horst von Brand wrote:

[...]

Quoted 5 lines

Quoted 2 lines
The problem (AFAIU) is that if the levels aren't set on startup, they are random in some cases.
So set them on startup. NOT when the driver is first loaded. Put it in the rc.d scripts.

There is a noticeable delay between to moment the module is insmod(8)ed, and the moment when its settings are set by the startup script. Not funny if it is going full blast ATM.

Signature · 6 lines

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-07 08:46 UTC #84 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 8 lines · Horst von Brand

Quoted 1 line · James A. Sutherland
On Mon, 06 Nov 2000, Horst von Brand wrote:
[...]
Quoted 2 lines
Quoted 2 lines
The problem (AFAIU) is that if the levels aren't set on startup, they are random in some cases.

Quoted 6 lines

Quoted 2 lines
So set them on startup. NOT when the driver is first loaded. Put it in the rc.d scripts.
There is a noticeable delay between to moment the module is insmod(8)ed, and the moment when its settings are set by the startup script. Not funny if it is going full blast ATM.

Yes, I know. That's why the driver MUST NOT change the volume settings when insmod(8)ed, waiting instead until it gets specific settings from the script, at which point it can initialise the card to the correct settings without a delay.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 17:09 UTC #85 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 3 lines · [email protected] said:

Yippee. As we all know, implementing GUI volume controls and putting
the slider in the right place is a kernel function, and nothing to do with userspace...

Don't troll, James. The kernel needs to provide the functionality required by userspace. The functionality required in this case is the facility to read the current mixer levels.

Quoted 4 lines · [email protected] said:

The right thing in this context is not to screw with hardware
settings unless and until it is given settings to set. Do not set values arbitrarily: set only the values you are explicitly given. Anything else is simply a bug in your driver.

It is unwise to assume that the hardware is in a sane state when the driver has been unloaded and reloaded. I agree that you should set the values that were explicitly given. That's why we should remember them.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-06 17:37 UTC #86 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 8 lines · David Woodhouse

Quoted 3 lines · [email protected] said:
Yippee. As we all know, implementing GUI volume controls and putting
the slider in the right place is a kernel function, and nothing to do with userspace...
Don't troll, James. The kernel needs to provide the functionality required by userspace. The functionality required in this case is the facility to read the current mixer levels.

Except this isn't possible with the hardware in question! If it were, there would be no problem. In cases where the hardware doesn't support the functionality userspace "needs", why put the kludge in the kernel?

If userspace wants to know what settings it set last time, it should store those values somewhere.

Quoted 9 lines

Quoted 4 lines · [email protected] said:
The right thing in this context is not to screw with hardware
settings unless and until it is given settings to set. Do not set values arbitrarily: set only the values you are explicitly given. Anything else is simply a bug in your driver.
It is unwise to assume that the hardware is in a sane state when the driver has been unloaded and reloaded. I agree that you should set the values that were explicitly given. That's why we should remember them.

No values are being explicitly given. Loading the driver should not cause any settings to be changed: changing the settings should do that!

There is no need for the drivers to change any settings. If the settings need to be (re)set, let userspace do it.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 17:44 UTC #87 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 6 lines · [email protected] said:

Except this isn't possible with the hardware in question! If it were,
there would be no problem. In cases where the hardware doesn't support the functionality userspace "needs", why put the kludge in the kernel?
If userspace wants to know what settings it set last time, it should store those values somewhere.

No. You have to reset the hardware fully each time you load the module. Although you _expect_ it to be in the state in which you left it, you can't be sure of that.

Quoted 7 lines · [email protected] said:

Eh? You just load the driver once, probably on boot, to configure sane values. This time round, you use an argument (or an ioctl or whatever) to specify the values you want. (cat /etc/sysconfig/sound/ defaultvolume > /dev/sound/mixer or whatever). After that, the module can be unloaded and loaded as needed, without any need to touch the mixer settings except in response to *explicit* "set volume" commands from userspace.

Agreed. Where 'whatever' == persistent storage of some form. I care not what form that takes. If you can store the data entirely in userspace and still have them present at the time the driver initialises the hardware, that's fine.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-06 17:56 UTC #88 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 11 lines · David Woodhouse

Quoted 6 lines · [email protected] said:
Except this isn't possible with the hardware in question! If it were,
there would be no problem. In cases where the hardware doesn't support the functionality userspace "needs", why put the kludge in the kernel?
If userspace wants to know what settings it set last time, it should store those values somewhere.
No. You have to reset the hardware fully each time you load the module. Although you _expect_ it to be in the state in which you left it, you can't be sure of that.

If a reset is needed, I think it should come explicitly from userspace.

Quoted 9 lines

Quoted 7 lines · [email protected] said:
Eh? You just load the driver once, probably on boot, to configure sane values. This time round, you use an argument (or an ioctl or whatever) to specify the values you want. (cat /etc/sysconfig/sound/ defaultvolume > /dev/sound/mixer or whatever). After that, the module can be unloaded and loaded as needed, without any need to touch the mixer settings except in response to *explicit* "set volume" commands from userspace.

Quoted 4 lines

Agreed. Where 'whatever' == persistent storage of some form. I care not what form that takes. If you can store the data entirely in userspace and still have them present at the time the driver initialises the hardware, that's fine.

That's what I've been getting at all along...

Probably have a simple load and unload script, which dumps state to a file on unload, and restores it on load. Whenever the module's state is not saved, the refcount is >0, so you can't unload it without saving state.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Evan Jeffrey

2000-11-06 20:47 UTC #89 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 9 lines · David Woodhouse

Quoted 5 lines
No. You have to reset the hardware fully each time you load the module. Although you _expect_ it to be in the state in which you left it, you can't
be sure of that.
If a reset is needed, I think it should come explicitly from userspace.

Take Alan's example of a USB device, say USB audio. If it is disconnected and reconnected to add a hub, or anything else, the device may shut itself down, go to an undefined state, or even power cycle (if it draws power from the USB +5V). Same with hot-swap PCI cards. The driver *MUST* reset the device on load. If saving mixer levels through this kind of transition is desired (which it evidentally is), the module load/unload code must save and restore the settings.

This is exactly equivelent to reseting hardware after a warm boot. Who knows what the Windows driver did to your card in the mean time. A device driver can only guarantee that nobody horkes with its hardware while it is loaded-- In the interim, the driver may have been connected to another computer, accessed by another driver, or accessed from userspace (say, VMWare doing a pass through driver).

I personally like the idea of having insmod/rmmod do copy-out/copy-in from a cache file in userspace. That way, if we need large data sets (a ROM image for something.) they don't take up kernel space when not in use. Also, it allows people to have persistant settings across reboot through the same mechanism--avoiding duplicating information in shutdown/startup scripts.

Evan
---
Fear is the mind killer. -- Frank Herbert, "Dune"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-07 00:27 UTC #90 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 9 lines · Evan Jeffrey

Quoted 8 lines · David Woodhouse
Quoted 5 lines
No. You have to reset the hardware fully each time you load the module. Although you _expect_ it to be in the state in which you left it, you can't
be sure of that.
If a reset is needed, I think it should come explicitly from userspace.

Quoted 7 lines

Take Alan's example of a USB device, say USB audio. If it is disconnected and reconnected to add a hub, or anything else, the device may shut itself down, go to an undefined state, or even power cycle (if it draws power from the USB +5V). Same with hot-swap PCI cards. The driver *MUST* reset the device on load. If saving mixer levels through this kind of transition is desired (which it evidentally is), the module load/unload code must save and restore the settings.

I'm not convinced.

Quoted 1 line

This is exactly equivelent to reseting hardware after a warm boot.

Interesting. If that were done, my last sound card wouldn't have worked at all under Linux: it had to be initialised under DOS before loading Linux. Had Linux then reset everything, I'd have been soundless!

Quoted 2 lines

Who knows
what the Windows driver did to your card in the mean time.

Either it initialises it (as it does, in this case), and I want (even NEED) it to STAY initialised (i.e. if your driver does an unnecessary reset, your driver is broken), or it doesn't, and I'll reset the card with an ioctl.

Quoted 5 lines

A device driver
can only guarantee that nobody horkes with its hardware while it is loaded-- In the interim, the driver may have been connected to another computer, accessed by another driver, or accessed from userspace (say, VMWare doing a pass through driver).

So provide the FACILITY to reset the card, IFF it is needed. There are cases where resetting the card is just stupid: don't force stupidity by design into the kernel.

Quoted 6 lines

I personally like the idea of having insmod/rmmod do copy-out/copy-in from a cache file in userspace. That way, if we need large data sets (a ROM image for something.) they don't take up kernel space when not in use. Also, it allows people to have persistant settings across reboot through the same mechanism--avoiding duplicating information in shutdown/startup scripts.

I prefer the idea of the drivers which need this coming with a suitable interface (/dev or /proc item) and a script to do this when needed.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Gerhard Mack

2000-11-06 23:28 UTC #91 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 17 lines · James A. Sutherland

Except this isn't possible with the hardware in question! If it were, there would be no problem. In cases where the hardware doesn't support the functionality userspace "needs", why put the kludge in the kernel?
If userspace wants to know what settings it set last time, it should store those values somewhere.
Quoted 9 lines
Quoted 4 lines · [email protected] said:
The right thing in this context is not to screw with hardware
settings unless and until it is given settings to set. Do not set values arbitrarily: set only the values you are explicitly given. Anything else is simply a bug in your driver.
It is unwise to assume that the hardware is in a sane state when the driver has been unloaded and reloaded. I agree that you should set the values that were explicitly given. That's why we should remember them.

Quoted 8 lines

No values are being explicitly given. Loading the driver should not cause any settings to be changed: changing the settings should do that!
There is no need for the drivers to change any settings. If the settings need to be (re)set, let userspace do it.
James.

Sure .. lets see you start a laptop in class or buisness meeting and have everyone turn to look at you wondering why your laptop let off an ear piercing shreak because the hardware defaults to all settings max.

And you will _STILL_ have that shriek for 1/2 - 1 second before the userspace app loads.

And no we couldn't unplug either the mike or the speakers since they come embedded in the laptop's case.

I don't see in any of your trolling an answer for this problem.

Gerhard

--
Gerhard Mack

[email protected]

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-07 00:36 UTC #92 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 26 lines · Gerhard Mack

Quoted 24 lines · James A. Sutherland
Except this isn't possible with the hardware in question! If it were, there would be no problem. In cases where the hardware doesn't support the functionality userspace "needs", why put the kludge in the kernel?
If userspace wants to know what settings it set last time, it should store those values somewhere.
Quoted 9 lines
Quoted 4 lines · [email protected] said:
The right thing in this context is not to screw with hardware
settings unless and until it is given settings to set. Do not set values arbitrarily: set only the values you are explicitly given. Anything else is simply a bug in your driver.
It is unwise to assume that the hardware is in a sane state when the driver has been unloaded and reloaded. I agree that you should set the values that were explicitly given. That's why we should remember them.
No values are being explicitly given. Loading the driver should not cause any settings to be changed: changing the settings should do that!
There is no need for the drivers to change any settings. If the settings need to be (re)set, let userspace do it.

Quoted 5 lines

Quoted 1 line
James.
Sure .. lets see you start a laptop in class or buisness meeting and have everyone turn to look at you wondering why your laptop let off an ear piercing shreak because the hardware defaults to all settings max.

That only happens if the driver is stupid enough to try guessing "correct" volume settings. If it leaves well alone until it KNOWS the correct settings, there is no ear piercing shriek. Nor is there any break in the sound if you were listening to something from the mixer.

Quoted 2 lines

And you will _STILL_ have that shriek for 1/2 - 1 second before the userspace app loads.

Wrong. The userspace app is the one triggering the device init, when it gives the sound driver the correct volume settings. There is no half second delay.

Quoted 4 lines

And no we couldn't unplug either the mike or the speakers since they come embedded in the laptop's case.
I don't see in any of your trolling an answer for this problem.

It isn't trolling, and there is a perfectly simple answer, as I have already explained.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Gerhard Mack

2000-11-07 00:40 UTC #93 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 16 lines · James A. Sutherland

Quoted 3 lines · Gerhard Mack
Sure .. lets see you start a laptop in class or buisness meeting and have everyone turn to look at you wondering why your laptop let off an ear piercing shreak because the hardware defaults to all settings max.
That only happens if the driver is stupid enough to try guessing "correct" volume settings. If it leaves well alone until it KNOWS the correct settings, there is no ear piercing shriek. Nor is there any break in the sound if you were listening to something from the mixer.
Quoted 2 lines
And you will _STILL_ have that shriek for 1/2 - 1 second before the userspace app loads.
Wrong. The userspace app is the one triggering the device init, when it gives the sound driver the correct volume settings. There is no half second delay.

Quoted 8 lines

Quoted 4 lines
And no we couldn't unplug either the mike or the speakers since they come embedded in the laptop's case.
I don't see in any of your trolling an answer for this problem.
It isn't trolling, and there is a perfectly simple answer, as I have already explained.

And if I don't use modules?

Gerhard

--
Gerhard Mack

[email protected]

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-07 00:45 UTC #94 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 21 lines · Gerhard Mack

Quoted 19 lines · James A. Sutherland
Quoted 3 lines · Gerhard Mack
Sure .. lets see you start a laptop in class or buisness meeting and have everyone turn to look at you wondering why your laptop let off an ear piercing shreak because the hardware defaults to all settings max.
That only happens if the driver is stupid enough to try guessing "correct" volume settings. If it leaves well alone until it KNOWS the correct settings, there is no ear piercing shriek. Nor is there any break in the sound if you were listening to something from the mixer.
Quoted 2 lines
And you will _STILL_ have that shriek for 1/2 - 1 second before the userspace app loads.
Wrong. The userspace app is the one triggering the device init, when it gives the sound driver the correct volume settings. There is no half second delay.
Quoted 3 lines
And no we couldn't unplug either the mike or the speakers since they come embedded in the laptop's case.

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
I don't see in any of your trolling an answer for this problem.
It isn't trolling, and there is a perfectly simple answer, as I have already explained.
And if I don't use modules?

Then none of this is relevant to you, since you can't unload any modules! And now you're the one doing the trolling... WTF do you think module code is supposed to do when you don't use modules?!

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Gerhard Mack

2000-11-07 01:18 UTC #95 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines

Then none of this is relevant to you, since you can't unload any modules! And now you're the one doing the trolling... WTF do you think module code is supposed to do when you don't use modules?!

Simple ... I'd rather the hardware was set to 0 on startup but I know what problems that presents to modules..

And no it wasn't the driver doing it afik. Sound card starts on max volume as soon as it's initialised.

Gerhard

--
Gerhard Mack

[email protected]

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-07 08:44 UTC #96 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 10 lines · Gerhard Mack

Quoted 4 lines
Then none of this is relevant to you, since you can't unload any modules! And now you're the one doing the trolling... WTF do you think module code is supposed to do when you don't use modules?!
Simple ... I'd rather the hardware was set to 0 on startup but I know what problems that presents to modules..
And no it wasn't the driver doing it afik. Sound card starts on max volume as soon as it's initialised.

Which is why I want the driver to initialise the card to "known-good" settings. Defaulting to 0 is not good enough.

With my approach, the driver is loaded as part of the kernel, but does NOT initialise the card, it just confirms it is there. Then, during boot, a script will initialise the sound card with the correct settings explicitly. That way, the delay between card init and the card getting the correct settings is minimal, even on broken hardware like this.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Horst von Brand

2000-11-07 02:38 UTC #97 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

"James A. Sutherland" <[email protected]> said:

[...]

Quoted 2 lines

That only happens if the driver is stupid enough to try guessing "correct" volume settings.

It did not touch anything: By a fluke, or by default, the sound output was going full blast, and the mike input was patched over to it ==> feedback shriek until (a few tenths of second later) the volume settings _were_ set.

Signature · 6 lines

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 17:14 UTC #98 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines

So autoload the module with a "dont_screw_with_mixer" option. When the kernel first boots, initialise the mixer to suitable settings (load the module with "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change the mixer settings on load.

Which is part of what persistent module data lets you do. And without having to mess with dont_screw_with_mixer (which if you get it wrong btw can be fatal and hang the hardware)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-06 17:41 UTC #99 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 8 lines · Alan Cox

Quoted 4 lines
So autoload the module with a "dont_screw_with_mixer" option. When the kernel first boots, initialise the mixer to suitable settings (load the module with "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change the mixer settings on load.
Which is part of what persistent module data lets you do. And without having to mess with dont_screw_with_mixer (which if you get it wrong btw can be fatal and hang the hardware)

Eh? You just load the driver once, probably on boot, to configure sane values. This time round, you use an argument (or an ioctl or whatever) to specify the values you want. (cat /etc/sysconfig/sound/defaultvolume > /dev/sound/mixer or whatever). After that, the module can be unloaded and loaded as needed, without any need to touch the mixer settings except in response to *explicit* "set volume" commands from userspace.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Paul Jakma

2000-11-06 18:39 UTC #100 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines · Alan Cox

Which is part of what persistent module data lets you do. And without having to mess with dont_screw_with_mixer (which if you get it wrong btw can be fatal and hang the hardware)

the sound card case for persistent modules is contentious i think.

what other good reasons are there for persistent data?

--paulj

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 21:30 UTC #101 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 2 lines

the sound card case for persistent modules is contentious i think. what other good reasons are there for persistent data?

Maintaining TV tuning
Maintaining configuration options for USB
Maintaining radio tuner frequencies
Speeding up module reloading (avoiding expensive re-inits - eg 30 seconds for i2o_scsi)
Remembering IDE tuning options across ide module unloads
Avoiding rescanning the scsi bus on a scsi module reload
...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Dan Hollis

2000-11-06 18:56 UTC #102 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines · James A. Sutherland

So autoload the module with a "dont_screw_with_mixer" option. When the kernel first boots, initialise the mixer to suitable settings (load the module with "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change the mixer settings on load.

You are asking for real trouble on hotplug hardware if you insist on this.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-07 00:20 UTC #103 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 7 lines · Dan Hollis

Quoted 4 lines · James A. Sutherland
So autoload the module with a "dont_screw_with_mixer" option. When the kernel first boots, initialise the mixer to suitable settings (load the module with "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change the mixer settings on load.
You are asking for real trouble on hotplug hardware if you insist on this.

How so? There is no need for the driver to decide off its own bat to go changing settings. If I plug in a hotplug soundcard and load the driver, I do NOT want the driver to decide to set some settings. If I want settings set, I'll do it myself (or have a script to do it).

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-07 00:29 UTC #104 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 3 lines

changing settings. If I plug in a hotplug soundcard and load the driver, I do NOT want the driver to decide to set some settings. If I want settings set, I'll do it myself (or have a script to do it).

How about if your stuff is already nicely set up and you remove then replug a device, or remove and swap for an identical replacement part. Most people then want the configuration preserved.

And guess what the simple modutils solution using an ELF section solves that too Want to go to default configuration ?

rm /var/run/modules/eth0.data

or wrap it in a GUI.

[BTW windows gets the USB speaker state management right, seems they store all the module persistent data in the registry!]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-07 00:44 UTC #105 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 6 lines · Alan Cox

Quoted 3 lines
changing settings. If I plug in a hotplug soundcard and load the driver, I do NOT want the driver to decide to set some settings. If I want settings set, I'll do it myself (or have a script to do it).
How about if your stuff is already nicely set up and you remove then replug a device,

When I plug it in and modprobe is triggered to load the driver, a script then runs to feed the device appropriate configuration info. Since the driver only resets the hardware when it is given the correct configuration, there's no problem.

Quoted 2 lines

or remove and swap for an identical replacement part. Most people then want the configuration preserved.

Hmm... define "identical". I take a laptop home, use a USB NIC to talk to my LAN at home (using NAT) with a 192.168.* address. Then I take it elsewhere and use the same model of NIC on the college LAN. All of a sudden, I get myself banging on the door complaining about misconfigured NICs :-)

Quoted 6 lines

And guess what the simple modutils solution using an ELF section solves that too Want to go to default configuration ?
rm /var/run/modules/eth0.data
or wrap it in a GUI.

That sounds a lot like what I've been advocating all along, if that file is created/updated by a script when eth0's driver is unloaded, then fed back to eth0 on load.

Quoted 2 lines

[BTW windows gets the USB speaker state management right, seems they store all the module persistent data in the registry!]

Yes, that's what we need. A registry, so configuration problems can be persistent across boots, and even reinstallations... ;-)

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-07 12:09 UTC #106 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines

When I plug it in and modprobe is triggered to load the driver, a script then runs to feed the device appropriate configuration info. Since the driver only resets the hardware when it is given the correct configuration, there's no problem.

Thats another 100 lines of race prone network kernel code you dont need

Quoted 1 line

Hmm... define "identical". I take a laptop home, use a USB NIC to talk to my

Same Mac address or same serial number.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-07 12:17 UTC #107 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 6 lines · Alan Cox

Quoted 4 lines
When I plug it in and modprobe is triggered to load the driver, a script then runs to feed the device appropriate configuration info. Since the driver only resets the hardware when it is given the correct configuration, there's no problem.
Thats another 100 lines of race prone network kernel code you dont need

Getting rid of 100 lines of code would certainly be worth doing...

Assuming I want the same configuration for the hardware as I did the last time I used it is OK - provided that assumption is NOT in the kernel. As a default behaviour in userspace, it's fine.

In the NIC example, I might well want the DHCP client to run whenever I activate the card. Bringing the NIC up with the old configuration - which, with dynamic IP addresses, could now include someone else's IP address! - is worse than useless.

Quoted 3 lines

Quoted 1 line
Hmm... define "identical". I take a laptop home, use a USB NIC to talk to my
Same Mac address or same serial number.

So if I take the NIC with me, Linux automagically misconfigures it for me. No thanks.

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-07 12:37 UTC #108 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines

In the NIC example, I might well want the DHCP client to run whenever I activate the card. Bringing the NIC up with the old configuration - which, with dynamic IP addresses, could now include someone else's IP address! - is worse than useless.

You'll notice the pcmcia subsystem already handles this, and keeps data in user space although it doesnt support saving it back. And it all works

In your case it would be something like

eth0 pegasus
nopersist eth0
post-install eth0 /usr/local/sbin/my-dhcp-stuff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James A. Sutherland

2000-11-07 12:51 UTC #109 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 5 lines · Alan Cox

Quoted 4 lines
In the NIC example, I might well want the DHCP client to run whenever I activate the card. Bringing the NIC up with the old configuration - which, with dynamic IP addresses, could now include someone else's IP address! - is worse than useless.

Quoted 8 lines

You'll notice the pcmcia subsystem already handles this, and keeps data in user space although it doesnt support saving it back. And it all works
In your case it would be something like
eth0 pegasus
nopersist eth0
post-install eth0 /usr/local/sbin/my-dhcp-stuff

So, in short, this is already done perfectly well in userspace without some sort of Registry-style kernelside hack?

James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-07 12:54 UTC #110 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 6 lines

Quoted 3 lines
eth0 pegasus
nopersist eth0
post-install eth0 /usr/local/sbin/my-dhcp-stuff
So, in short, this is already done perfectly well in userspace without some sort of Registry-style kernelside hack?

Thats the idea. Once the rmmod code can read back values the cycle is complete and the kernel doesnt care

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Petko Manolov

2000-11-07 12:52 UTC #111 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 6 lines · Alan Cox

Quoted 5 lines
In the NIC example, I might well want the DHCP client to run whenever I activate the card. Bringing the NIC up with the old configuration - which, with dynamic IP addresses, could now include someone else's IP address! - is worse than useless.

Quoted 8 lines

You'll notice the pcmcia subsystem already handles this, and keeps data in user space although it doesnt support saving it back. And it all works
In your case it would be something like
eth0 pegasus
nopersist eth0
post-install eth0 /usr/local/sbin/my-dhcp-stuff

Oops! Don't try to do this with pegasus.c older than 0.4.13. I have set the ethernet address at open time, which breaks dhcpd. I fixed that in test-10, but it's release took a long time.

Sorry if the note doesn't make sense, i didn't follow the thread from the beginning.

Petkan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Martin Dalecki

2000-11-06 14:22 UTC #112 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 22 lines · David Woodhouse

Quoted 5 lines · [email protected] said:
* Driver initializes mixer to 100% muted * Userspace app sets desired
values to /dev/mixer * Userspace app opens /dev/dsp to play sound
I don't see where any sound can "escape" in this scenario, and it doesn't require any module data persistence...
* User boots kernel
* User loads mixer app
* Sound module is autoloaded, defaults to zero levels. This is fine.
* User sets 'line in' level to appropriate level to listen to radio
* User closes mixer app
* Time passes
* Sound module is unloaded
* User continues to happily listen to radio through sound card
* Time passes
* User is listening intently to something on the radio
* Something wants to beep through /dev/audio
* Sound module is autoloaded again, default to zero levels. This time it is _NOT_ fine. User is rightly pissed off :)

Quoted 6 lines

It's fine to default to zero levels the first time the sound module is loaded after booting. Not on subsequent reloads though.
A long time ago, I made the sb16 driver use the persistent storage facility of kerneld to store mixer levels. I was happy with this right up until kerneld disappeared :)

It was removed for good reasons.

Quoted 6 lines

I then made a version which read the current mixer levels back from the hardware on initialisation, and didn't reset them. That didn't work on all sb16 hardware, but it worked for me (tm).
Persistent storage is the best way to do it though. It doesn't have to be persistent over reboots, just during the lifetime of the kernel.

No! The best way to do it are just *persistently loaded* modules. It's THAT simple!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 17:21 UTC #113 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 5 lines

Quoted 2 lines
Persistent storage is the best way to do it though. It doesn't have to be persistent over reboots, just during the lifetime of the kernel.
No! The best way to do it are just *persistently loaded* modules. It's THAT simple!

So you want to split every sound driver into two or more modules ?

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 17:35 UTC #114 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 3 lines · [email protected] said:

Quoted 2 lines
No! The best way to do it are just *persistently loaded* modules. It's THAT simple!

So you want to split every sound driver into two or more modules ?

The point here is that although I've put up with just keeping the sound driver loaded for the last few years, permanently taking up a large amount of DMA memory, the inter_module_xxx stuff that Keith is proposing would give us a simple way of storing the data which we want to store.

It's even simpler (and cleaner) than having to split all the sound drivers up into data and worker modules.

Someone suggested combining the 'data' modules so that one data module was shared by different 'worker' modules.

Build that into the kernel rather than making it a module.

Call its functions 'inter_module_get' et al.

We seem to have returned to what I was suggesting in the first place.

Being able to do it completely in userspace would be neater, though.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Oliver Xymoron

2000-11-06 18:23 UTC #115 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines · David Woodhouse

The point here is that although I've put up with just keeping the sound driver loaded for the last few years, permanently taking up a large amount of DMA memory, the inter_module_xxx stuff that Keith is proposing would give us a simple way of storing the data which we want to store.

...

Quoted 1 line

Being able to do it completely in userspace would be neater, though.

I think there are a bunch of other devices that need stuff from userspace before they fully init, namely the ones that load proprietary firmware images. Will an approach like that work here?

Alternately, we could have a "virtual module" called mixer-settings-n, which when requested would tell modprobe to call a program to do its fiddly things but wouldn't actually load a module.

The virtual module idea is ugly, yes, and perhaps what's needed is a more generic userspace hook interface. Something that merged what /sbin/hotplug, /sbin/modprobe, and the much-talked-about devfsd-like notifier are supposed to do.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 18:38 UTC #116 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 7 lines · Oliver Xymoron

Quoted 4 lines · David Woodhouse
The point here is that although I've put up with just keeping the sound driver loaded for the last few years, permanently taking up a large amount of DMA memory, the inter_module_xxx stuff that Keith is proposing would give us a simple way of storing the data which we want to store.

Quoted 6 lines

...
Quoted 1 line
Being able to do it completely in userspace would be neater, though.
I think there are a bunch of other devices that need stuff from userspace before they fully init, namely the ones that load proprietary firmware images. Will an approach like that work here?

Some devices have a firmware.h that is compiled into the driver. A few sound devices use a function that loads a firmware file from userspace, given a filename. The comment in drivers/sound/sound_firmware.c says that this is a poor method, and that the recommended method for uploading firmware to a device is via ioctl.

Jeff

Signature · 8 lines

Jeff Garzik             | "When I do this, my computer freezes."
Building 1024           |          -user
MandrakeSoft            | "Don't do that."
                        |          -level 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Oliver Xymoron

2000-11-06 19:10 UTC #117 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 15 lines · Jeff Garzik

Quoted 7 lines · Oliver Xymoron
Quoted 4 lines · David Woodhouse
The point here is that although I've put up with just keeping the sound driver loaded for the last few years, permanently taking up a large amount of DMA memory, the inter_module_xxx stuff that Keith is proposing would give us a simple way of storing the data which we want to store.
Quoted 6 lines
...
Quoted 1 line
Being able to do it completely in userspace would be neater, though.
I think there are a bunch of other devices that need stuff from userspace before they fully init, namely the ones that load proprietary firmware images. Will an approach like that work here?

Quoted 5 lines

Some devices have a firmware.h that is compiled into the driver. A few sound devices use a function that loads a firmware file from userspace, given a filename. The comment in drivers/sound/sound_firmware.c says that this is a poor method, and that the recommended method for uploading firmware to a device is via ioctl.

Ioctl (or alternate device for plan9 groupies) is fine. My point is final initialization of the device is obviously delayed until the firmware is loaded. Adopting a similar strategy for initializing mixers (possibly falling back to initializing with zero levels) minimizes the window between resetting a device and having sane mixer settings.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Horst von Brand

2000-11-07 01:27 UTC #118 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Oliver Xymoron <[email protected]> say:

[...]

Quoted 3 lines

Ioctl (or alternate device for plan9 groupies) is fine. My point is final initialization of the device is obviously delayed until the firmware is loaded.

Let's play perverse: What if I load the module, but don't initialize the firmware, then unload? The fact that the firmware has been initialized has to be kept somewhere...

Signature · 7 lines

Horst von Brand                             [email protected]
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 21:20 UTC #119 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to David Woodhouse

Quoted 5 lines

Some devices have a firmware.h that is compiled into the driver. A few sound devices use a function that loads a firmware file from userspace, given a filename. The comment in drivers/sound/sound_firmware.c says that this is a poor method, and that the recommended method for uploading firmware to a device is via ioctl.

modutils has a post-install facility that supports firmware load via ioctl beautifully too

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Oliver Xymoron

2000-11-06 07:29 UTC #120 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 9 lines · David Woodhouse

Quoted 3 lines · Oliver Xymoron
Hopefully not. The standard examples (mixer levels, etc) are better handled with a userspace tool hooked by modprobe. This even gets persistence across reboots if that's what's wanted.
Implement a way for a userspace tool to get the correct mixer levels in place at the time the sound hardware is reset, so there are no glitches in the levels, and I'll agree with you.

If I understand you correctly:

process 1 process 2
open(/dev/dsp)
modprobe->
load module
init module (can't remember which context, actually)
start writing
set mixer levels

Is there any reason we ever want to unblock process 1 before process 2 terminates?

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 07:33 UTC #121 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 11 lines · Oliver Xymoron

If I understand you correctly:
process 1 process 2
open(/dev/dsp)
modprobe->
load module
init module (can't remember which context, actually)
start writing
set mixer levels

Quoted 2 lines

Is there any reason we ever want to unblock process 1 before process 2 terminates?

No, and I don't think we do. That's not the point.

'init module' is still _after_ 'set mixer levels'. There is a period during which the mixer levels are changed.

The desired mixer levels should be available to the module at the time of initialisation.

Signature · 7 lines

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2000-11-06 07:46 UTC #122 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 2 lines · David Woodhouse

The desired mixer levels should be available to the module at the time of initialisation.

For drivers built into the kernel that gets messy. The command line is only so long. Sounds messy for modules too. Further (responding to your other e-mail), few probably care about having the mixer containing default, not custom, values for 10 seconds between driver init and aumix execution from initscripts...

It sounds smarter to delay mixer initialization, or mute all mixer channels at init. That effectively initializes the mixer channels to the custom values you desire, without having to add special case module gunk for the subset of people who need correct mixer values Right Now(tm).

Jeff

Signature · 7 lines

Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 08:00 UTC #123 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 9 lines · Jeff Garzik

Quoted 2 lines · David Woodhouse
The desired mixer levels should be available to the module at the time of initialisation.
For drivers built into the kernel that gets messy. The command line is only so long. Sounds messy for modules too. Further (responding to your other e-mail), few probably care about having the mixer containing default, not custom, values for 10 seconds between driver init and aumix execution from initscripts...

I don't mean this to happen on boot. As you say, that gets messy. The first time a module is loaded after booting, the levels can be all zeroed.

I'm more interested in the case where the module is loaded for the second time:

User loads a mixer to set the 'line' level to something sensible so he can listen to the radio, which is routed through the sound card to his amp.

User closes mixer program. Module is unloaded. Levels remain the same - all is well.

Some time later, something tries to 'beep' via /dev/audio. Module is reloaded, the feed the user was listening to is interrupted.

Actually, the way it happened to me was that it was five in the morning, I was in halls of residence, and suddenly I was playing the radio at full volume :)

After fixing the sb16 driver to use the existing persistent storage, and watching that facility disappear from the module support shortly thereafter, I just decided not to autoload the sound modules.

Signature · 7 lines

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andrew Pimlott

2000-11-06 13:43 UTC #124 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to David Woodhouse

Quoted 2 lines · David Woodhouse

I'm more interested in the case where the module is loaded for the second time:

Is there really a reason to unload a module in normal usage? Beyond miniscule memory savings and hack value? You can solve the whole problem with a loud "don't do that".

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Oliver Xymoron

2000-11-06 07:48 UTC #125 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 5 lines · David Woodhouse

Quoted 3 lines · Oliver Xymoron
If I understand you correctly:
process 1 process 2

...

Quoted 8 lines

Quoted 3 lines
Is there any reason we ever want to unblock process 1 before process 2 terminates?
No, and I don't think we do. That's not the point.
'init module' is still _after_ 'set mixer levels'. There is a period during which the mixer levels are changed.

Perhaps you mean before? Otherwise you've lost me.

Quoted 2 lines

The desired mixer levels should be available to the module at the time of initialisation.

Is this because active audio sources other than /dev/dsp writers are suddenly in and out of the mix? If there's nothing on the inputs, it shouldn't matter whether you're changing the levels.

The right way to do this (according to any sound engineer) is to initialize all the levels to zero unless told otherwise. This would doubtless annoy the average user, but is more or less equivalent to not forwarding packets by default.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse

2000-11-06 08:03 UTC #126 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 4 lines · Oliver Xymoron

Quoted 2 lines
'init module' is still _after_ 'set mixer levels'. There is a period during which the mixer levels are changed.
Perhaps you mean before? Otherwise you've lost me.

Yeah, sorry, not enough coffee yet this morning.

Quoted 6 lines

Quoted 2 lines
The desired mixer levels should be available to the module at the time of initialisation.
Is this because active audio sources other than /dev/dsp writers are suddenly in and out of the mix? If there's nothing on the inputs, it shouldn't matter whether you're changing the levels.

Yes.

Quoted 4 lines

The right way to do this (according to any sound engineer) is to initialize all the levels to zero unless told otherwise. This would doubtless annoy the average user, but is more or less equivalent to not forwarding packets by default.

The current situation is equivalent to stopping forwarding packets each time an app on the local machine decides it wants to send its own packets, after a period of inactivity.

Defaulting to zero on boot is fine. Defaulting to zero after the module has been auto-unloaded and auto-loaded again is less good.

Signature · 7 lines

dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman

2000-11-06 19:34 UTC #127 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 6 lines · David Woodhouse

The current situation is equivalent to stopping forwarding packets each time an app on the local machine decides it wants to send its own packets, after a period of inactivity.
Defaulting to zero on boot is fine. Defaulting to zero after the module has been auto-unloaded and auto-loaded again is less good.

Well we don't have auto unload.
And module persistent data for the second load case causes chaos with the goal of having exactly the same code in modules and compiled in kernel code.

It would probably be better (in this case) to increment the module count when the mixer settings go above 0, and decrement it when the settings go totally to 0. This prevents an unwanted unload.

But for reliability and code simplicity there does not yet seem to be a case for persistent module storage.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox

2000-11-06 21:19 UTC #128 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 3 lines

It would probably be better (in this case) to increment the module count when the mixer settings go above 0, and decrement it when the settings go totally to 0. This prevents an unwanted unload.

Thats about 200 lines of code and also about 50,000 emails complaining people cannot unload sound stuff.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Helge Hafting

2000-11-07 09:55 UTC #129 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

Quoted 7 lines · Alan Cox

Quoted 4 lines
It would probably be better (in this case) to increment the module count when the mixer settings go above 0, and decrement it when the settings go totally to 0. This prevents an unwanted unload.
Thats about 200 lines of code and also about 50,000 emails complaining people cannot unload sound stuff.

Still, it is so logical. Modules cannot be unloaded when in use. "use" is usually "someone having the device open". But "someone listening to pass-through sound" is effectively using the mixer - the module is in use in another way. Network drivers don't have a /dev/xxx to open/close either.

Having to turn off the master volume before unloading makes sense to me. (The driver may still free up DMA buffers when nobody need them, i.e. when /dev/dsp haven't been used for some time.)

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Keith Owens

2000-11-07 02:09 UTC #130 lore raw

Re: Persistent module storage [was Linux 2.4 Status / TODO page]

In reply to Eric W. Biederman

Quoted 1 line · On 06 Nov 2000 11:09:41 -0700, [email protected] (Eric W. Biederman) wrote:

Well we don't have auto unload.

Check crontab, if it contains rmmod -a then you have auto unload.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Stephen C. Tweedie

2000-11-04 13:14 UTC #131 lore raw