Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
All, Please reply to [EMAIL PROTECTED] rather than this email account. Regards, Dave Jeff Garzik wrote: [EMAIL PROTECTED]">Andi Kleen wrote: de4x5 is stable, but tends to perform badly under load, mostly becauseit doesn't use rx_copybreak and overflows standard socket buffers with itsalways MTU sized skbuffs. One of the reasons that de4x5 isn't gone already is that I get reportsthat de4x5 performs better than the tulip driver for their card. Jeff
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
All, As you can see, I get little time to attend to maintenance chores on the de4x5 driver. If there are particular problems that you want sorted out please let me know and I'll see what I can do. Regards, Dave -- Jeff Garzik wrote: > Andi Kleen wrote: > >> de4x5 is stable, but tends to perform badly under load, mostly because >> it doesn't use rx_copybreak and overflows standard socket buffers with its >> always MTU sized skbuffs. > > > One of the reasons that de4x5 isn't gone already is that I get reports > that de4x5 performs better than the tulip driver for their card. > > Jeff > > - 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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
In message <[EMAIL PROTECTED]> you write: > > 12. Probably Post 2.4 > > > * module remove race bugs (ipchains modules -- Rusty; won't fix for > >2.4) > > Is this an ipchains bug, or a more general module subsystem bug? There's a fundamental problem with any module which reduces counts in interrupts. Viro's `solution' doesn't apply here; there is a real solution but I Believed In The Code Freeze. Rusty. -- Hacking time. - 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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, Nov 12, 2000 at 10:09:39PM -0500, Jeff Garzik wrote: > [EMAIL PROTECTED] wrote: > > 4. Boot Time Failures > > > * Various Alpha's don't boot under 2.4.0-test9 (PCI-PCI bridges are > >not configured correctly Michal Jaegermann; Richard Henderson may > >have an idea what's failing.) > > Move to patch-exists-but-not-merged. rth has patches, co-developed with > Ivan Kokshaysky Would be nice, wouldn't it. Unfortunately this is not the case. rth has patches which help to boot his machine, and few others, but this still does not work in general. Ivan works now pretty hard, with my involvment into this, trying to identify and fix the problem. Michal - 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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Mon, Nov 13, 2000 at 11:58:00PM +0100, Roger Larsson wrote: > On Sunday 12 November 2000 23:31, Erik Mouw wrote: > > I can still hang the system with XMMS (1.0.1) using real-time priority. > > The system doesn't die, but it is completely unresponsive. There is no > > sound, but after the MP3 file is played, the system works again. I can > > reproduce this behaviour with usb-uhci and uhci-alt on 2.4.0-test10. > > I haven't test test11-pre3 yet, but the changes don't look too big that > > the "bug" has been fixed. > > Does it use non blocking IO? > In such case you might have created an infinite loop at high priority > resulting in a busylock of all other processes. Possible, I didn't look at the source. It would explain the behaviour, but why isn't there any sound? Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - 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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sunday 12 November 2000 23:31, Erik Mouw wrote:
> On Sun, Nov 12, 2000 at 02:39:09PM -0500, [EMAIL PROTECTED] wrote:
> > * USB: system hang with USB audio driver {CRITICAL} (David
> >Woodhouse, Randy Dunlap, Narayan Desai) (Fixed with usb-uhci;
> >uhci-alt is unknown -- randy dunlap)
>
> I can still hang the system with XMMS (1.0.1) using real-time priority.
> The system doesn't die, but it is completely unresponsive. There is no
> sound, but after the MP3 file is played, the system works again. I can
> reproduce this behaviour with usb-uhci and uhci-alt on 2.4.0-test10.
> I haven't test test11-pre3 yet, but the changes don't look too big that
> the "bug" has been fixed.
>
Does it use non blocking IO?
In such case you might have created an infinite loop at high priority
resulting in a busylock of all other processes.
> BTW, I don't think this is a critical bug.
>
>
> Erik
--
Home page:
http://www.norran.net/nra02596/
-
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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, Nov 12, 2000 at 02:39:09PM -0500, [EMAIL PROTECTED] wrote: > Fixed > > * Zip/Imm/Parport will reliably hang the system (James M. "Dart", >fixed) This isn't fixed, I'm pretty sure. I haven't looked at it yet. Tim. */ PGP signature
Re: Linux 2.4 Status/TODO page (test11-pre3)
> >8. Fix Exists But Isnt Merged
> > * VGA Console can cause SMP deadlock when doing printk {CRITICAL}
> > (Keith Owens)
>
> Fix (by whom?)
Me :-)
> included in 2.4.0-test11-pre3. Looks good.
-
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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
Figures. I'll be quick to blame esd, it does pretty much all writes blind. -d Matti Aarnio wrote: > On Sun, Nov 12, 2000 at 07:26:37PM -0800, David Ford wrote: > > [EMAIL PROTECTED] wrote: > > > Fixed > > > * Incredibly slow loopback tcp bug (believed fixed about 2.3.48) > > > > Note; if I set up ESD to listen on a tcp port, connecting locally sounds > > horrible. I haven't looked to see who's fault it really is. > > FTP-transfer of large file over loopback gives me about 80 MB/sec > speeds at 2.4.0-test8 -- nor is the ESD bad sounding. > > However my Alpha has the SB support very bad sounding.. > It sounds like spectrum reversal, in fact -- first noticed > when playing stereophonic MP3 with xmms, but when same file > was played to .WAV file at an intel box (where it sounds quite > ok), and that wav is play(1)ed at the alpha -- same bad sound. > > > -d > > /Matti Aarnio -- ---NOTICE -- fwd: fwd: fwd: type emails will be deleted automatically. "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - 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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, Nov 12, 2000 at 07:26:37PM -0800, David Ford wrote: > [EMAIL PROTECTED] wrote: > > Fixed > > * Incredibly slow loopback tcp bug (believed fixed about 2.3.48) > > Note; if I set up ESD to listen on a tcp port, connecting locally sounds > horrible. I haven't looked to see who's fault it really is. FTP-transfer of large file over loopback gives me about 80 MB/sec speeds at 2.4.0-test8 -- nor is the ESD bad sounding. However my Alpha has the SB support very bad sounding.. It sounds like spectrum reversal, in fact -- first noticed when playing stereophonic MP3 with xmms, but when same file was played to .WAV file at an intel box (where it sounds quite ok), and that wav is play(1)ed at the alpha -- same bad sound. > -d /Matti Aarnio - 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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, Nov 12, 2000 at 02:39:09PM -0500, [EMAIL PROTECTED] wrote:
> * USB: fix setting urb->dev in printer, acm, bluetooth, all serial
>drivers (Greg KH) {CRITICAL} (test10-pre1)
Confirmed, this is in the latest version and is fixed.
thanks,
greg k-h
--
greg@(kroah|wirex).com
http://immunix.org/~greg
-
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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
Jeff Garzik wrote: > > * 2.4.0-test10 pcmcia fails to detect IRQ's correctly, and will > >sometimes kill all software interrupts on card insertion on a NEC > >Versa LX (David Ford) > > Still does this with test11-pre-latest? I'll test this tomorrow, I can't interrupt my laptop for the evening. -d -- ---NOTICE -- fwd: fwd: fwd: type emails will be deleted automatically. "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - 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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
[EMAIL PROTECTED] wrote:
> 4. Boot Time Failures
> * Various Alpha's don't boot under 2.4.0-test9 (PCI-PCI bridges are
>not configured correctly Michal Jaegermann; Richard Henderson may
>have an idea what's failing.)
Move to patch-exists-but-not-merged. rth has patches, co-developed with
Ivan Kokshaysky
> 8. Fix Exists But Isnt Merged
> * Many network device drivers don't call MOD_INC_USE_COUNT in
>dev->open. (Paul Gortmaker has patches)
Update: net drivers can now set an owner member as of test11-pre3, to
completely eliminate any race. Net drivers that don't call MOD_xxx at
all should just be updated to use the new stuff.
> * using ramfs with highmem enabled can yield a kernel NULL pointer
>dereference. (wollny at cns.mpg.de has a patch)
fixed as of test11-pre2.
> 9. To Do
> * Fix mount failures due to copy_* user mishandling
Details?
> * Misc locking problems
> + Power management locking (Alan Cox)
A patch from Alan for this made it into test10 or test11-pre1.
> * Copying between two encrypting loop devices causes an immediate
>deadlock in the request queue (Andi Kleen)
Loopback block device has serious problems, not just this.. I am gonna
look at it this week...
> * 2.4.0-test10 pcmcia fails to detect IRQ's correctly, and will
>sometimes kill all software interrupts on card insertion on a NEC
>Versa LX (David Ford)
Still does this with test11-pre-latest?
> * VGA Console can cause SMP deadlock when doing printk {CRITICAL}
>(Keith Owens)
move to "should already be fixed, confirmation wanted." I think Keith
said he doesn't exercise that particular code path anymore, so he didn't
test James' patch.
> * drivers/input/mousedev.c dereferences userspace pointers directly
>(prumpf)
yum :)
> 10. To Do But Non Showstopper
>
> * Go through as 2.4pre kicks in and figure what we should mark
>obsolete for the final 2.4 (i.e. XT hard disk support?)
* Go through as 2.4pre kicks in and figure out what FOO_DEBUG options
need to be turned off. __iovirt_debug is a notable one that will hurt
performance (IMHO), because every write[bwl] gets routed to a function
call that checks stuff before performing the I/O.
> * Union mount (Al Viro)
I think this is complete? Isn't this mount --bind?
> * 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)
Maybe combine this entry and the loopback crypto one above into a more
general "loopback works for some cases, deadlocks for others"
> 11. To Check
> * NFS bugs are fixed
Is this worthy of an entry? I think that every bug fix applied should
have a listing here, then. :) check that parport bugs are fixed.
check that serial bugs are fixed. etc. ...
> * List of potential problems found by Stanford students using g++
>hacks:
> + Andy Chou's list of mismatched spinlocks and interrupts/bh
> enable/disable.
> + Seth Andrew Hallem's list potentially sleeping functions
> called with interrupts off or spinlocks held.
> + Dawson Engler's list of potential kmalloc/kfree bugs
A few people are hanging onto these lists, and going through them. This
could be an 'in progress' item.
> * Potential races in file locking code (Christian Ehrhardt -- patch
>which may fix some of these posted by trond, at
>http://boudicca.tux.org/hypermail/linux-kernel/2000week45/0404.htm
>l)
I think trond's patch was applied.
> * many drivers are not hot-plugging safe (__devinit/__devexit)
>(Barklomiej Zolnierkiewicz)
Many drivers are not supposed to be hotplug safe!
If the hardware is not known to be hotpluggable, then the driver should
not use __devinit/exit. Doing so needlessly avoids the __init code
drop, wasting memory.
> 12. Probably Post 2.4
> * module remove race bugs (ipchains modules -- Rusty; won't fix for
>2.4)
Is this an ipchains bug, or a more general module subsystem bug?
> * NCR5380 isnt smp safe (Frank Davis --- belives the driver should
>be rewritten)
hehe I personally believe many of the current kernel drivers should be
rewritten ;-)
Jeff
--
Jeff Garzik |
Building 1024 | Would you like a Twinkie?
MandrakeSoft|
-
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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, 12 Nov 2000 14:39:09 -0500,
[EMAIL PROTECTED] wrote:
>6. In Progress
> * DRM and MTD cannot use AGP support module when CONFIG_MODVERSIONS
> is defined (issue with get_module_symbol caused fix proposed by
> John Levon to be rejected) (Keith Owens has fix)
Fix included in 2.4.0-test11-pre1. I have seen no problems, apart from
dwwm who wants the interface backported to 2.2, but that is a separate
issue.
>8. Fix Exists But Isnt Merged
> * VGA Console can cause SMP deadlock when doing printk {CRITICAL}
> (Keith Owens)
Fix (by whom?) included in 2.4.0-test11-pre3. Looks good.
-
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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, Nov 12, 2000 at 02:39:09PM -0500, [EMAIL PROTECTED] wrote:
> * USB: system hang with USB audio driver {CRITICAL} (David
>Woodhouse, Randy Dunlap, Narayan Desai) (Fixed with usb-uhci;
>uhci-alt is unknown -- randy dunlap)
I can still hang the system with XMMS (1.0.1) using real-time priority.
The system doesn't die, but it is completely unresponsive. There is no
sound, but after the MP3 file is played, the system works again. I can
reproduce this behaviour with usb-uhci and uhci-alt on 2.4.0-test10.
I haven't test test11-pre3 yet, but the changes don't look too big that
the "bug" has been fixed.
BTW, I don't think this is a critical bug.
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, 12 Nov 2000, adrian wrote: > vt82c686a. Also, I can't seem to find which VPx is generally associated Heh.pci.ids Regards, Adrian - 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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, 12 Nov 2000, adrian wrote: > Does this include VPx were x does not exist? Geez. Excuse me. I should watch my assumptions. Out of curiosity, is there a reason why lspci reports vt82c586 and the kernel reports vt82c686a at bootup? The board is documented to have the vt82c686a. Also, I can't seem to find which VPx is generally associated with which southbridge. Regards, Adrian - 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/
Re: Linux 2.4 Status/TODO page (test11-pre3)
On Sun, 12 Nov 2000 [EMAIL PROTECTED] wrote: [snip] > 2. Capable Of Corrupting Your FS/data > > * Use PCI DMA by default in IDE is unsafe (must not do so on via >VPx, x < 3) (Vojtech Pavlik --- requires chipset tuning to be >enabled according to Andre Hedrick --- we need to turn this on by >default, if it is safe -- TYT) [snip] Does this include VPx were x does not exist? (vt82c686a VIA Apollo VP, specifically Asus K7M) Regards, Adrian - 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/
Linux 2.4 Status/TODO page (test11-pre3)
OK, here's an updated version of the TODO list.
The version on linux24.sourceforge.net hasn't been updated over the
weekend, due to the SSH daemon on the sourceforge projects server being
dead. I'll get the web version synced up by tomorrow, hopefully.
- Ted
Linux 2.4 Status/TODO Page
This list is almost always out of date, by definition, since kernel
development moves so quickly. I try to keep it as up to date as
possible, though. Please send updates to [EMAIL PROTECTED]
Every few days or so, I periodically send updated versions of this
list to the linux-kernel list, but you should consult
http://linux24.sourceforge.net to get the latest information.
If you're curious to see what has changed recently, check out
http://linux24.sourceforge.net/status-changes.html. The previous set
of changes can be found here. Also, this html file is managed under
CVS at SourceForge.
I try to keep e-mail addresses out of this document, since I don't
want to make life easy for bottom-feeder spam artists. If you are a
developer and want to contact the person who originally reported the
problem, or want to see the e-mail message which prompted me to
include a bug/issue in this list, contact me. I keep an mail archive
which will have that information assuming it was an item added since I
took over the list from Alan.
Last modified: [tytso:20001112.1433EST]
Hopefully up to date as of: test11pre3
1. Should Be Fixed Already (Confirmation Wanted)
* Fbcon races (cursor problems when running continual streaming
output mixed with printk + races when switching from X while doing
continuous rapid printing --- Alan)
* USB: system hang with USB audio driver {CRITICAL} (David
Woodhouse, Randy Dunlap, Narayan Desai) (Fixed with usb-uhci;
uhci-alt is unknown -- randy dunlap)
* USB: fix setting urb->dev in printer, acm, bluetooth, all serial
drivers (Greg KH) {CRITICAL} (test10-pre1)
* USB: race conditions on devices in use and being unplugged
(test10)
* USB: printer Device ID string should not be static; printers can
update it (test10)
* USB: fix hub driver allocation/usage of portstr & tempstr (D.
Brownell) (causes oops and memory corruptoin) {CRITICAL} (test10)
* USB: SMP/concurrent/thread-safe for scanner.c, mdc800.c, rio800.c
(test10)
* USB: printer open should not fail on printer not ready; add
GETSTATUS ioctl (2.4.0-test10)
2. Capable Of Corrupting Your FS/data
* Use PCI DMA by default in IDE is unsafe (must not do so on via
VPx, x < 3) (Vojtech Pavlik --- requires chipset tuning to be
enabled according to Andre Hedrick --- we need to turn this on by
default, if it is safe -- TYT)
* USB: Problems with USB storage drives (ORB, maybe Zip) during APM
sleep/suspend
* Bug in VFAT truncate code will cause slow and painful corruption
of filesystem (Ivan Baldo, Alan Cox)
3. Security
* Fix module remove race bug (still to be done: TTY, ldisc, I2C,
video_device - Al Viro) (Rogier Wolff will handle ATM)
4. Boot Time Failures
* Use PCI DMA 'lost interrupt' problem with PIIXn tuning enabled
will hang laptop requiring physical power loss to restart (NEC
Versa LX, 2.3.x to 2.4.0-test8-pre6, David Ford) (Vojtech Pavlik
is looking at this)
* Crashes on boot on some Compaqs ? (may be fixed)
* Various Alpha's don't boot under 2.4.0-test9 (PCI-PCI bridges are
not configured correctly Michal Jaegermann; Richard Henderson may
have an idea what's failing.)
* Compaq proliant 7000 (with Compaq Smart Array-3100ES) hangs during
2.4.0-test9. Likely related to the Raid driver given where it hung
in the boot messages (chonga at isoft)
* Crashes soon after decompressing on Sparcstation 10 (Rafal
Mazkowski)
5. Compile errors
6. In Progress
* Finish the audit/code review of the code dealing with descriptor
tables. (Al Viro)
* DMFE is not SMP safe (Frank Davis patch exists, but hasn't gotten
much commens yet; Jeff Garzik says needs to protect access to
multiple hw registers)
* Fixing autofs4 to deal with VFS changes (Jeremy Fitzhardinge)
* The new hot plug PCI interface does not provide a method for
passing the correct device name to cardmgr (David Hinds, a an)
* DRM and MTD cannot use AGP support module when CONFIG_MODVERSIONS
is defined (issue with get_module_symbol caused fix proposed by
John Levon to be rejected) (Keith Owens has fix)
7. Obvious Projects For People (well if you have the hardware..)
* Make syncppp use new ppp code
* Fix SPX socket code
8. Fix Exists But Isnt Merged
* Restore O_SYNC functionality
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
Date: Fri, 3 Nov 2000 17:10:52 -0800 (PST)
From: James Simmons <[EMAIL PROTECTED]>
> * 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/
tulip vs. de4x5 (was Re: Linux 2.4 Status / TODO page ...)
Jeff Garzik wrote: > > > de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is > duplicated now in tulip driver. > I've got some DEC Miatas with DECchip 21142/43 ethernet cards, and I don't get the same link speeds when using the de4x5 and tulip drivers, as of 2.4.0-test10. The machines are connected to a Netgear 16-port 10/100 hub. With the tulip driver the hub shows a 10 Mb/s connection; with the de4x5 driver the hub shows a 100 Mb/s connection. In both cases the drivers are configured into the kernel, not as modules, if it matters. Am I doing something wrong, or is this a known issue? FWIW, these machines are diskless, and according to the hub they download the kernel at 100 Mb/s. When the tulip-based kernel initializes the card, the hub shows the link speed switching to 10 Mb/s. from lspci -v: 00:03.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30) Flags: bus master, medium devsel, latency 255, IRQ 24 I/O ports at 8000 [size=128] Memory at 0900 (32-bit, non-prefetchable) [size=128] Expansion ROM at 0904 [disabled] [size=256K] de4x5 boot messages: eth0: DC21143 at 0x8000 (PCI bus 0, device 3), h/w address 00:00:f8:76:3c:74, and requires IRQ24 (provided by PCI BIOS). de4x5.c:V0.545 1999/11/28 [EMAIL PROTECTED] tulip boot messages: Linux Tulip driver version 0.9.10 (September 6, 2000) eth0: Digital DS21143 Tulip rev 48 at 0x8000, 00:00:F8:76:3C:74, IRQ 24. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. eth0: Index #2 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block. eth0: Index #3 - Media AUI (#2) described by a 21142 Serial PHY (2) block. eth0: Index #4 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: MII transceiver #5 config 2000 status 784b advertising 01e1. -- Jim - James A. Schutt [EMAIL PROTECTED] - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Alan Cox wrote: > 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/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
Date: Fri, 03 Nov 2000 17:20:53 -0500 From: Jeff Garzik <[EMAIL PROTECTED]> > 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). > * 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/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
[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 -- 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/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
[EMAIL PROTECTED] wrote: >> * 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. -- 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/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
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/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
Date: Fri, 3 Nov 2000 15:53:34 + (GMT) From: Alan Cox <[EMAIL PROTECTED]> > * 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? > * 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> > eth0pegasus > > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Alan Cox wrote: > > > 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 > > eth0pegasus > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 07 Nov 2000, Alan Cox wrote: > > 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 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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 eth0pegasus 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> Plese add power-saving devices like in notebooks to the list as well. > For example in my notebook the PC speaker loops through the maestro-3e. > The BIOS is initializing the maestro with some sane mixer values but > after > a suspend cycle the pc speaker is compleatly off due to suspension of > the Then you APM bios is not to specification. Don't inflict your bios bugs on everyone but forcing policy. - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 07 Nov 2000, Alan Cox wrote: > > 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. > > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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 > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Martin Mares wrote: > > Hi Alan! > > > If the sound card is only used some of the time or setup and then used > > for TV its nice to get the 60K + 128K DMA buffer back when you dont need it > > especially on a low end box > > So why don't we allocate / free the DMA buffer on device open / close instead > of module insert / remove? If the reason lies in problems with allocation > of large chunks of contiguous memory, we're going to have exactly the same > problems when autoloading the module. > > I think that automatic loading / unloading of modules has been a terrible hack > since its first days (although back in these times a useful one) and that the > era of its usefulness is over. There are zillions of problems with this > mechanism, the most important ones being: Amen. >o It would have to preserve _complete_ device state over module reload. > For the sound card mixer settings discussed it's close to trivial, but > for example consider a tape drive and the problem of preserving tape > position after reload (probably including device reset causing tape rewind). > And what about textures loaded to memory of a 3D video card? > >o For many drivers, the "device currently open" concept makes no sense. > Consider a mouse driver whose only activity is to feed mouse events > to an event device. The mouse driver can be unloaded in any time (either > manually or perhaps automatically after the mouse gets unplugged), hence > it should have a use count == zero, but even if it seems to be unused, > it must not be unloaded just because of some timeout since the mouse > will cease to work. > >o It interferes with hotplug in nasty ways. Let's have a USB host controller > driver with currently no devices on its bus. It's also an example of a zero > use count driver, but it also must not be unloaded as it's needed for > recognizing newly plugged in devices. Plese add power-saving devices like in notebooks to the list as well. For example in my notebook the PC speaker loops through the maestro-3e. The BIOS is initializing the maestro with some sane mixer values but after a suspend cycle the pc speaker is compleatly off due to suspension of the maestro-3e chip and the leak of a *permanent* driver sitting around to handle the wakeup event. > I don't argue whether we need or need not some kind of persistent storage for > the modules (it might be a good idea when it comes to hotplug, but it should > be probably taken care of by the userspace hotplug helpers), but I think that > it has no chance to solve the problems with automatic unloading. > > We could of course attempt to circumvent the problems listed above by adding > some hints to module state which will say whether it's possible to auto-unload > the module or not even if it has zero use count, but it means another thing > to handle in all the drivers (well, at least another thing to think of whether > it's needed or not for each driver) and I think that the total effect of > the autounloading mechanism (a minimum amount of memory saved) in no way > outweighs the cost of implementing it right. And the pain for the user of the whole: Take the example of ALSA over-modularisation... - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Hello Horst!
> Strange somebody from a distribution forgets _the_ most important use of
> modules: Remember old-time Slackware, with dozens of different boot
> diskettes, and the imperative to compile a kernel to your machine once you
> got it running?
But how is this related to automatic unloading of modules???
Even automatic loading is not needed for this purpose -- just make the startup
scripts load all the modules needed and you don't have to maintain complex
mappings from userspace device names to kernel drivers.
> The cases mentioned are cases where unloading (automatic or manual, doesn't
> matter) would break things. Just don't allow it, ever (IPv6 does this, for
> one example). Or fix the loading/unloading somehow. Strategies to be able
> to do so is what is being discussed here, BTW...
No, the cases mentioned are cases where automatic unloading breaks things,
but manual unloading is perfectly okay. Nobody expects you to preserve exact
hardware state and keep things working if you unload the driver manually,
but automatic unload should be perfectly transparent.
> Just force a non-zero count as long as the module is in use. Wait a
> minute... that is exactly what a non-zero count is supposed to mean!
Yes, but define "in use". Does your "in use" mean "referenced by user space
or by other drivers" (== cannot be unloaded without crashing the system)
or "unloading this module makes something cease to work"? Currently, the
use counts maintained by the drivers correspond to the first definition
which is the right definition when it comes to manual unloading, but it
gives you no clue when it comes to transparent automatic unloading.
> What is a "minimal ammount of memory" on the 1+Gb RAM machines I've seen
> discussed here isn't at all "minimal" for somebody who has to run Linux in
> 4Mb, preferably less...
> Linux came to be what it is today in large part because the PC nobody
> wanted anymore ("too slow", "can't run XYZ") became the router/firewall/web
> server/mail server/... over in some closet, and soon nobody even remembered
> where the machine was physically. Don't kill this.
In routers dreaming the ancient dreams from the elder days of their creation,
you need all the modules loaded all the time anyway, hence automatic unloading
doesn't apply. Even better use a monolithic kernel since it saves in average
half a page per driver. (Yes, I know that current distributions don't ship with
precompiled kernels suiting your machine, but current distributions don't run
on a 4MB 386 anyway.)
Also, I'm not advocating killing compatibility with such old hardware (which
I frequently use), but I'd very much like to avoid hacking all the drivers
just to support correctly some (although sometimes useful) ill defined feature.
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
"ADA -- A Dumb Acronym"
-
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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Alan Cox wrote: > > > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Horst von Brand wrote: > "James A. Sutherland" <[EMAIL PROTECTED]> said: > > On Mon, 06 Nov 2000, Horst von Brand wrote: > > [...] > > > > 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. 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 07 Nov 2000, Gerhard Mack wrote: > > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
I've seen the same arguments over and over again here. It seems that there are two feasible ways to accomplish persistence: totally kernel and totally user-space The totally kernel-space people want to make a way for modules to store persistent data, either in memory, or across boots on disk. These people seem to debate whether modules should be unloaded/loaded upon suspend/resume. Among the user-space people, there are some who want the status quo, where the driver initializes the card, and then a user proggy sets it up the way it really should be, which causes the gap problem. There was also a suggestion (which sounded pretty interesting) where the driver would not initialize the card until prompted to do so by a user-space program, which would also give it the correct settings. It seems that the big problem with this is that the card may not get initialized when it needs to be. The initialization/state-saver proggy may have to be called: on boot, on suspend, on restore, when the hardware is physically removed and replaced, when something goes wrong and the user wants to reset things, and on shutdown. I just wanted to try to get all the arguments together on one page. I hope I didn't miss anything, or make any big mistakes. My own guess is that the first option is the most reliable, and that the last one is the most flexible. -- This message has been brought to you by the letter alpha and the number pi. David Feuer [EMAIL PROTECTED] - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
"James A. Sutherland" <[EMAIL PROTECTED]> said: [...] > 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. -- 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000 23:00:05 + (GMT), Paul Jakma <[EMAIL PROTECTED]> wrote: >On Mon, 6 Nov 2000, Alan Cox wrote: >> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Martin Mares <[EMAIL PROTECTED]> said:
[...]
> I think that automatic loading / unloading of modules has been a terrible hack
> since its first days (although back in these times a useful one) and that the
> era of its usefulness is over. There are zillions of problems with this
> mechanism, the most important ones being:
Strange somebody from a distribution forgets _the_ most important use of
modules: Remember old-time Slackware, with dozens of different boot
diskettes, and the imperative to compile a kernel to your machine once you
got it running?
>o It would have to preserve _complete_ device state over module
> reload.
If too hard, just leave it alone: Don't allow unloading.
>o For many drivers, the "device currently open" concept makes no
> sense.
Ditto.
>o It interferes with hotplug in nasty ways. Let's have a USB host
> controller driver with currently no devices on its bus. It's also an
> example of a zero use count driver, but it also must not be unloaded
> as it's needed for recognizing newly plugged in devices.
Ditto.
> I don't argue whether we need or need not some kind of persistent storage
> for the modules (it might be a good idea when it comes to hotplug, but it
> should be probably taken care of by the userspace hotplug helpers), but I
> think that it has no chance to solve the problems with automatic
> unloading.
The cases mentioned are cases where unloading (automatic or manual, doesn't
matter) would break things. Just don't allow it, ever (IPv6 does this, for
one example). Or fix the loading/unloading somehow. Strategies to be able
to do so is what is being discussed here, BTW...
> We could of course attempt to circumvent the problems listed above by
> adding some hints to module state which will say whether it's possible to
> auto-unload the module or not even if it has zero use count,
Just force a non-zero count as long as the module is in use. Wait a
minute... that is exactly what a non-zero count is supposed to mean!
> but it means
> another thing to handle in all the drivers (well, at least another thing
> to think of whether it's needed or not for each driver) and I think that
> the total effect of the autounloading mechanism (a minimum amount of
> memory saved) in no way outweighs the cost of implementing it right.
What is a "minimal ammount of memory" on the 1+Gb RAM machines I've seen
discussed here isn't at all "minimal" for somebody who has to run Linux in
4Mb, preferably less...
Linux came to be what it is today in large part because the PC nobody
wanted anymore ("too slow", "can't run XYZ") became the router/firewall/web
server/mail server/... over in some closet, and soon nobody even remembered
where the machine was physically. Don't kill this.
--
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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Oliver Xymoron <[EMAIL PROTECTED]> say: [...] > 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... -- 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
David Woodhouse <[EMAIL PROTECTED]> said: [...] > 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? -- 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
David Woodhouse <[EMAIL PROTECTED]> said: > [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? -- 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
"James A. Sutherland" <[EMAIL PROTECTED]> said: > On Mon, 06 Nov 2000, Horst von Brand wrote: [...] > > 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. -- 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 07 Nov 2000, Gerhard Mack wrote: > On Tue, 7 Nov 2000, James A. Sutherland wrote: > > > On Mon, 06 Nov 2000, Gerhard Mack wrote: > > > 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. > > > > > 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. > > > > > 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? 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 07 Nov 2000, Alan Cox wrote: > > 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. > 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 :-) > 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. > [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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 7 Nov 2000, James A. Sutherland wrote: > On Mon, 06 Nov 2000, Gerhard Mack wrote: > > 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. > > > 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. > > > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Gerhard Mack wrote: > On Mon, 6 Nov 2000, James A. Sutherland wrote: > > > 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. > > > > > [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. > > 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. > 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. > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Evan Jeffrey wrote: > > On Mon, 06 Nov 2000, David Woodhouse wrote: > > > > > > 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. I'm not convinced. > 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! > 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. > 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. > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Dan Hollis wrote: > On Mon, 6 Nov 2000, James A. Sutherland wrote: > > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, James A. Sutherland wrote: > 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. > > > [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. 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, Alan Cox wrote: > 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, -- 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
This sounds to me like the most flexible way to do it. If the module accepts parameters then those who want the sound card initialized at every load can put the desired settings in modules.conf. The rest of us can just initialize it once at boot time and the rest of the time the settings will be left untouched. James A.Sutherland <[EMAIL PROTECTED]> on 11/06/2000 11:38:44 AM To: Alan Cox <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (James A. Sutherland) cc: [EMAIL PROTECTED] (David Woodhouse), [EMAIL PROTECTED] (Jeff Garzik), [EMAIL PROTECTED] (Dan Hollis), [EMAIL PROTECTED] (Alan Cox), [EMAIL PROTECTED] (Oliver Xymoron), [EMAIL PROTECTED] (Keith Owens), [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec) Subject: Re: Persistent module storage [was Linux 2.4 Status / TODO page] On Mon, 06 Nov 2000, Alan Cox wrote: > > 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/ - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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 > - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Hi Alan! > If the sound card is only used some of the time or setup and then used > for TV its nice to get the 60K + 128K DMA buffer back when you dont need it > especially on a low end box So why don't we allocate / free the DMA buffer on device open / close instead of module insert / remove? If the reason lies in problems with allocation of large chunks of contiguous memory, we're going to have exactly the same problems when autoloading the module. I think that automatic loading / unloading of modules has been a terrible hack since its first days (although back in these times a useful one) and that the era of its usefulness is over. There are zillions of problems with this mechanism, the most important ones being: o It would have to preserve _complete_ device state over module reload. For the sound card mixer settings discussed it's close to trivial, but for example consider a tape drive and the problem of preserving tape position after reload (probably including device reset causing tape rewind). And what about textures loaded to memory of a 3D video card? o For many drivers, the "device currently open" concept makes no sense. Consider a mouse driver whose only activity is to feed mouse events to an event device. The mouse driver can be unloaded in any time (either manually or perhaps automatically after the mouse gets unplugged), hence it should have a use count == zero, but even if it seems to be unused, it must not be unloaded just because of some timeout since the mouse will cease to work. o It interferes with hotplug in nasty ways. Let's have a USB host controller driver with currently no devices on its bus. It's also an example of a zero use count driver, but it also must not be unloaded as it's needed for recognizing newly plugged in devices. I don't argue whether we need or need not some kind of persistent storage for the modules (it might be a good idea when it comes to hotplug, but it should be probably taken care of by the userspace hotplug helpers), but I think that it has no chance to solve the problems with automatic unloading. We could of course attempt to circumvent the problems listed above by adding some hints to module state which will say whether it's possible to auto-unload the module or not even if it has zero use count, but it means another thing to handle in all the drivers (well, at least another thing to think of whether it's needed or not for each driver) and I think that the total effect of the autounloading mechanism (a minimum amount of memory saved) in no way outweighs the cost of implementing it right. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "A mathematician is a machine for converting coffee into theorems." - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> On Mon, 06 Nov 2000, David Woodhouse wrote: > > > > 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/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
Jeff Garzik wrote: > > Alan Cox wrote: > > > * 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. 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Alan Cox wrote: > A simple more generic solution is to do this [] > 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. -- ** [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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
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. David Woodhouse wrote: > > [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/ -- Tim Riker - http://rikers.org/ - short SIGs! 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
David Woodhouse <[EMAIL PROTECTED]> writes: > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, Jeff Garzik wrote: > Oliver Xymoron wrote: > > > > On Mon, 6 Nov 2000, David Woodhouse wrote: > > > > > 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. > > ... > > > 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. 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, James A. Sutherland wrote: > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, Alan Cox wrote: > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Oliver Xymoron wrote: > > On Mon, 6 Nov 2000, David Woodhouse wrote: > > > 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. > ... > > 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 -- 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, David Woodhouse wrote: > 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) > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, Alan Cox wrote: > If the sound card is only used some of the time or setup and then used > for TV its nice to get the 60K + 128K DMA buffer back when you dont need it > especially on a low end box > so unload it then - aiui most soundcards will continue passing through the TV line? right? or another argument: how common is this case that a box with such tight memory is used in such a multi-purpose way (sometimes it uses sounds, mostly not? and even then, for such a case, is it reasonable to assume the user should deal with the memory problems? (ie it's not unreasonable to expect them to have to do extra fiddling with mixer levels). but surely the vast majority of machines with soundcards have no good reason for unloading them? --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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, David Woodhouse wrote: > 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. ... > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, David Woodhouse wrote: > * 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. > 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. > 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) > -- > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, David Woodhouse wrote: > [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. > [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. 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, David Woodhouse wrote: > [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. > [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/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
Hello! > > Luckily, my old Multia died. 8) > > > > Jeff, tulip did not work with genuine Digital cards. > > I'm pretty sure I fixed that. Tested it on my Multia in fact :) (and > my AS200 too) > > The fix should be in 2.2.17 tulip.c, as well as 2.4.x... Then sed -e 's/Luckily/What a pity/' in may mail. 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
[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. [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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Alan Cox wrote: > > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, David Woodhouse wrote: > [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. > [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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
[EMAIL PROTECTED] said: > > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> Not quite: plugging physically hardware in and out is compleatly > different > then just loading a driver and unconditionally unloading it even when > the hardware is still there! Actually its no different. Suppose I unplug my USB speakers and plug them back in again (perhaps Im just adding a hub). Do you unload and reload the driver ? If so how do you preserve the mixer levels ? Same problem... - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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. > 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 > 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 > - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
[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/
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] > > [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/ > - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Alan Cox wrote: > > > >Just load the driver at bootup and forget about it. Problem solved. > > > > I daily curse the name of whoever added autoload and autounload. > > Autoload maybe useful, autounload is just asking for problems. > > Deal with it. Hardware is also now auto load and auto unloading too. For 2.5 > hopefully a lot of this can be tidied up and done better - persistent storage > in the modules that is written to disk and put back by insmod/rmmod (in > userspace) will help a lot. Not quite: plugging physically hardware in and out is compleatly different then just loading a driver and unconditionally unloading it even when the hardware is still there! - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
[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. [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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Horst von Brand wrote: > [Chopped down Cc: list] > "James A. Sutherland" <[EMAIL PROTECTED]> said: > > On Mon, 06 Nov 2000, David Woodhouse wrote: > > [...] > > > > 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 set them on startup. NOT when the driver is first loaded. Put it in the rc.d scripts. > So you'd have to save (at least) the fact that they > have been initalized. No, you don't. > 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. > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
[Chopped down Cc: list] "James A. Sutherland" <[EMAIL PROTECTED]> said: > On Mon, 06 Nov 2000, David Woodhouse wrote: [...] > > 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. -- 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, ChileFax: +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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, David Woodhouse wrote: > [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. > 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. > > > 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. > 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
David Woodhouse <[EMAIL PROTECTED]> said: > [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). -- 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, ChileFax: +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/
