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

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

[tytso]

Travel and other things have kept me more than a little busy lately, so
I fell a bit behind during the test10-pre* series, and didn't have a
chance to issue new updates of the 2.4 TODO list as often as I would
like.  I've caught up on my backlog, however, and this is as up to date
as I can make it as of 2.4.0-test10.

As always, the list isn't perfect.  Comments and reports of bugs fixed /
not fixed are welcome.  (Although for my sanity, please change the
subject line before replying.  :-)

						- 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 tytso@mit.edu.

   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:20001103.1002EST]

   Hopefully up to date as of: test10

1. Should Be Fixed (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 usbdevfs memset() on IOC_WRITE (Dan Streetman) {CRITICAL}
       (test10)
     * USB: fix hub driver allocation/usage of portstr & tempstr (D.
       Brownell) (causes oops and memory corruptoin) {CRITICAL} (test10)
     * USB: USB mouse stopped working (2.4.0-test9) (Gunther Mayer)
       (fixed in 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 resource
       allocation problem? Michal Jaegermann; Richard Henderson may have
       an idea what's failing.)
     * Palmax PD1100 hangs during boot since 2.4.0-test9 (Alan Cox)
     * 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)

5. Compile errors

6. In Progress

     * Fix all remaining PCI code to use pci_enable_device (mostly done)
     * 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)
     * Audit all char and block drivers to ensure they are safe with the
       2.3 locking - a lot of them are not especially on the
       read()/write() path. (Frank Davis --- moving slowly; if someone
       wants to help, contact Frank)
     * Fixing autofs4 to deal with VFS changes (Jeremy Fitzhardinge)

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 (CRITICAL, DB's depend on it)
       (Stephen)
     * Update SGI VisWS to new-style IRQ handling (Ingo)
     * Support MP table above 1Gig (Ingo)
     * Dont panic on boot when meeting HP boxes with wacked APIC table
       numbering (AC)
     * Scheduler bugs in RT (Dimitris)
     * AIC7xxx doesnt work non PCI ? (Doug says OK, new version due
       anyway)
     * Fix boards with different TSC per CPU and kill TSC use on them
     * IRDA fixes:
          + Fixes from DAG: Incluldes a number of critical bugfixes.
            Detailed listing of changes here:
               o irda1
               o irda2
               o irda3
          + Fixes from Jean Tourrilhes (Fixes critical bugs: Infinite
            loop in /proc/discovery, unsafe discovery entry removal,
            potential out of array access in QoS handling) (Functional
            bugs fixed: Zombie sockets disable listening socket, some
            discovery acses unhandled)
     * Many network device drivers don't call MOD_INC_USE_COUNT in
       dev->open. (Paul Gortmaker has patches)
     * using ramfs with highmem enabled can yield a kernel NULL pointer
       dereference. (wollny at cns.mpg.de has a patch)
     * Writing past end of removeable device can cause data corruption
       bugs in the future (Jari Ruusu)
     * fix the UFS and sysvfs races (the latter couple is broken as ext2
       was, UFS is _completely_ broken; eats filesystems) (Al Viro --
       patch mostly exists)
     * HT6560/UMC8672 ide sets up stuff too early (before region stuff
       can be done) (Andre Herick has fix)
     * mtrr.c is broken for machines with >= 4GB of memory (David Wragg
       has a fix)

9. To Do

     * truncate->invalidate_inode_pages removes mapping information from
       mapped pages which may be dirty; sync_pte -> crash. (CRITICAL)
       (sct, Linus and AL are looking at this)
     * VM: raw I/O data loss (raw IO may arrive in a page which afer it
       is unammped from a process) (CRITICAL) (rik van riel)
     * 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)
     * Tulip hang on rmmod/crashes sometimes
     * Devfs races (mostly done - Al Viro)
     * Fix further NFS races (Al Viro)
     * Test other file systems on write
     * Fix mount failures due to copy_* user mishandling
     * Check all file systems are either LFS compliant or error large
       files
     * Issue with notifiers that try to deregister themselves? (lnz;
       notifier locking change by Garzik should backed out, according to
       Jeff)
     * Misc locking problems
          + drivers/pcmcia/ds.c: ds_read & ds_write. SMP locks are
            missing, on UP the sleep_on() use is unsafe.
          + Power management locking (Alan Cox)
          + USB:
               o USB: fix MOD_INC races in plusb.c and uss720.c
               o USB: fix concurrent read/write and other SMP like bugs
                 in:
                    # acm.c
                    # printer.c
                    # uss720.c
                    # serial/ftdi_sio.c
                    # serial/omninet.c
          + do_execve (Al Viro, reported by Manfred)
          + fix the quota races (Al Viro)
     * SCSI CD-ROM doesn't work on filesystems with < 2kb block size
       (Jens Axboe will fix)
     * Remove (now obsolete) checks for ->sb == NULL (Al Viro)
     * Audit list of drivers that dereference ioremap's return (Abramo
       Bagnara)
     * ISAPnP can reprogram active devices (2.4.0-test5, Elmer Joandi,
       alan)
     * Multilink PPP can get the kernel into a tight loop which spams the
       console and freezes the machine (Aaron Tiensivu)
     * mm->rss is modified in some places without holding the
       page_table_lock (sct)
     * Copying between two encrypting loop devices causes an immediate
       deadlock in the request queue (Andi Kleen)
     * FAT filesystem doesn't support 2kb sector sizes (did under 2.2.16,
       doesn't under 2.4.0test7. Kazu Makashima, alan)
     * The new hot plug PCI interface does not provide a method for
       passing the correct device name to cardmgr (David Hinds, alan)
     * non-PNP SB AWE32 has tobles in 2.4.0-test7 and newer (Gerard
       Sharp) (Paul Laufer has a potential patch)
     * 2.4.0-test8 pcmcia is unusable in fall forms (kernel, mixed, or
       dhinds code) (David Ford)
     * VGA Console can cause SMP deadlock when doing printk {CRITICAL}
       (Keith Owens)
     * Forwawrd port 2.2 fixes to allow 2 GHz or faster CPU's. {CRITICAL}
     * IDE tape driver broken; if the last data written does not make up
       a full block, then the driver won't be able to read back ANY part
       of the last block (Mikael Pettersson, Alan Cox)
     * VM: Fix the highmem deadlock, where the swapper cannot create low
       memory bounce buffers OR swap out low memory because it has
       consumed all resources {CRITICAL} (old bug, already reported in
       2.4.0test6)
     * VM: page->mapping->flush() callback in page_lauder() for easier
       integration with journaling filesystem and maybe the network
       filesystems
     * VM: maybe rebalance the swapper a bit... we do page aging now so
       maybe refill_inactive_scan() / shm_swap() and swap_out() need to
       be rebalanced a bit
     * DRM cannot use AGP support module when CONFIG_MODVERSIONS is
       defined (issue with get_module_symbol caused fix proposed by John
       Levon to be rejected)
     * Spin doing ioctls on a down netdeice as it unloads == BOOM
       (prumpf, Alan Cox) Possible other net driver SMP issues (andi
       kleen)
     * USB: SANE backend can't communicate to its scanner (sometimes,
       some scanners)
     * USB: OHCI memory corruption problem
     * USB: Fix differences in UHCI and OHCI HCD behaviors/semantics:
          + OHCI doesn't do URB timeouts
          + OHCI always does BULK_QUEUE (as David.B said, Bulk queueing
            is a UHCI notion; not needed in OHCI; fix not needed)
     * USB: fix USB_QUEUE_BULK problem in uhci.c (oopsen after a while)
       {CRITICAL}
     * USB: Fix serial/omninet.c to not require a small mtu setting in
       order to get a PPP link to work properly (as reported by Bernhard
       Reiter)
     * USB: pegasus: avoid warning spewage on disconnect
     * USB: OHCI optional zero length packet (USB_DISABLE_SPD at send)
     * USB: consistent short packet handling OHCI/UHCI (including
       0-length packets) (Roman)
     * USB: consistent URB next pointer handling by OHCI/UHCI (Roman)

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?)
     * Union mount (Al Viro)
     * Per Process rtsigio limit
     * iget abuse in knfsd
     * ISAPnP IRQ handling failing on SB1000 + resource handling bug
     * Parallel ports should set SA_SHIRQ if PCI (eg in Plip)
     * Devfs compiled in but not mounted causes crap for ->mnt_devname of
       root (Al Viro)
     * PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is
       reliable)
          + PCMCIA crashes on unloading pci_socket
     * ATM phy-chip-driver interface change for Firestream ATM card
       (Rogier Wolff)
     * 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)
     * USB: acm (modem) driver is slow compared to Windows drivers for
       same modems (maybe an HCD problem, not acm driver, or acm should
       use bulk queueing)
     * USB: add devfs support to drivers that don't have it
     * USB: add DocBook info to main USB driver interfaces (usb.c)
     * USB: Printer stalls at random places when printing large graphics.
       When printing big pictures (10..50 meg) the printer stalls
       halfway. The point where it stalls is random but the fact that it
       stalls is reproducable. Printing the same pictures using the
       parallel interface is ok. Printing text is ok anyway. (Frank van
       Maarseveen)
     * USB: Misc locking problems: fix concurrent read/write and other
       SMP-like bugs in:
          + bluetooth.c
          + serial/keyspan.c
          + serial/whiteheat.c
     * USB: fix usb_unlink_urb() bug when called with an urb that was
       used on a device that is no longer registered in the USB system.
     * USB: control pipe locking (mutual exclusion)
     * USB: use pci_alloc_consistent throughout (mostly OHCI; some people
       want UHCI also)
     * RTL 8139 cards sometimes stop responding. Both drivers don't
       handle this quite good enough yet. (reported by Rogier Wolff,
       tentatively reported as fixed by David Ford; reports from Frank
       Jacobberger and Shane Shrybman indicate that it doesn't appear to
       be fixed in test9)
     * tty_register_devfs and tty_unregister_devfs declare struct
       tty_struct as a local, which causes stack overflows for user-mode
       linux. (Jeff Dike)

11. To Check

     * Check O_APPEND atomicity bug fixing is complete
     * Protection on i_size (sct) [Al Viro mostly done]
     * Mikulas claims we need to fix the getblk/mark_buffer_uptodate
       thing for 2.3.x as well
     * VFS?VM - mmap/write deadlock (demo code seems to show lock is
       there)
     * kiobuf seperate lock functions/bounce/page_address fixes
     * Fix routing by fwmark
     * rw semaphores on inodes to fix read/truncate races ? [Probably
       fixed]
     * Not all device drivers are safe now the write inode lock isnt
       taken on write
     * Multiwrite IDE breaks on a disk error [minor issue at best]
       (hopefully fixed)
     * ACPI/APM suspend issue - IDE related stuff ? (requires full
       taskfile support that was vetoed by Linus)
     * NFS bugs are fixed
     * Chase reports of SMB not working
     * Some AWE cards are not being found by ISAPnP ??
     * RAM disk contents vanishing on cramfs (block change) and bforget
       cases
     * Disappointing performance of Software Raid, esp. write performance
       (reported by Nils Rennebarth)
     * 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
     * Potential races in file locking code (Christian Ehrhardt)
          + locks_verify_area checks the wrong range if O_APPEND is set
            and the current file position is not at the end of the file.
          + dito if the file position changes between the call to
            locks_verify_area and the actual read/write (requires a
            shared file pointer, an attacker can use this to circumvent
            virtually any mandatory lock).
          + active writes should prevent anyone from getting mandatory
            locks for the area beeing written.
          + active reads should prevent anyone from getting mandatory
            write locks for the area beeing read.
     * Possible race in b-tree code for HFS, HPFS, NTFS: insert into the
       tree whild doing a readdir (Matthew Wilcox)
     * Stressing the VM (IOPS SPEC SFS) with HIGHMEM turned on can hang
       system (linux-2.4.0test5, Ying Chen, Rik van Riel)
     * Eepro100 driver can sometimes report out of resources on reboot
       (Josue Emmanuel Amaro)

12. Probably Post 2.4

     * per super block write_super needs an async flag
     * per file_op rw_kiovec
     * rw sempahores on page faults (mmap_sem) (Currently protected by
       mmap_sem)
     * module remove race bugs (ipchains modules -- Rusty; won't fix for
       2.4)
     * NCR5380 isnt smp safe (Frank Davis --- belives the driver should
       be rewritten)
     * VM: physical->virtual reverse mapping, so we can do much better
       page aging with less CPU usage spikes
     * VM: better IO clustering for swap (and filesystem) IO
     * VM: move all the global VM variables, lists, etc. into the pgdat
       struct for better NUMA scalability
     * VM: (maybe) some QoS things, as far as they are major improvements
       with minor intrusion
     * VM: thrashing control, maybe process suspension with some forced
       swapping ?
     * VM: include Ben LaHaise's code, which moves readahead to the VMA
       level, this way we can do streaming swap IO, complete with
       drop_behind()
     * USB: spread out interrupt frames for devices that use the same
       interrupt period (interval)
     * USB: add USB 2.0 EHCI HCD
     _________________________________________________________________

Fixed

     * Incredibly slow loopback tcp bug (believed fixed about 2.3.48)
     * COMX series WAN now merged
     * VM needs rebalancing or we have a bad leak
     * SHM works chroot
     * SHM back compatibility
     * Intel i960 problems with I2O
     * Symbol clashes and other mess from _three_ copies of zlib!
     * PCI buffer overruns
     * Shared memory changes change the API breaking applications (eg
       gimp)
     * Finish softnet driver port over and cleanups
     * via rhine oopses under load ? S
     * SCSI generic driver crashes controllers (need to pass
       PCI_DIR_UNKNOWN..)
     * UMSDOS fixups resync (not quite done)
     * Make NTFS sort of work
     * Any user can crash FAT fs code with ftruncate
     * AFFS fixups
     * Directory race fix for UFS
     * Security holes in execve()
     * Lan Media WAN update for 2.3
     * Get the Emu10K merged
     * Paride seems to need fixes for the block changes yet
     * Kernel corrupts fs and gs in some situations (Ulrich has demo
       code)
     * 1.07 AMI MegaRAID
     * Merge 2.2.15 changes (Alan) x
     * Get RAID 0.90 in (Ingo)
     * S/390 Merge
     * NFS DoS fix (security)
     * Fix Space.c duplicate string/write to constants
     * Elevator and block handling queue change errors are all sorted
     * Make sure all drivers return 1 from their __setup functions (Done
       ?)
     * Enhanced disk statistics
     * Complete vfsmount merge (Al Viro)
     * Merge removed-buf-open directory stuff into VFS (Al Viro)
     * Problems with ip autoconfig according to Zaitcev
     * NFS causes dup kmem_create on reload (Trond)
     * vmalloc(GFP_DMA) is needed for DMA drivers (Ingo)
     * TLB flush should use highest priority (Ingo)
     * SMP affinity code creates multiple dirs with the same name (Ingo)
     * Set SMP affinity mask to actual cpu online mask (needed for some
       boards) (Ingo)
     * heavy swapping corrupts ptes (believed so)
     * pci_set_master forces a 64 latency on low latency setting
       devices.Some boards require all cards have latency <= 32
     * msync fails on NFS (probably fixed anyway)
     * Find out what has ruined disk I/O throughput. (mostly)
     * PIII FXSAVE/FXRESTORE support
     * The netdev name changing stuff broke GRE
     * put_user is broken for i386 machines (security) - sem stuff may be
       wrong too
     * BusLogic crashes when you cat /proc/scsi/BusLogic/0 (Robert de
       Vries)
     * Finish sorting out VM balancing (Rik Van Riel, Juan Quintela et
       al)
     * Fix eth= command line
     * 8139 + bridging fails
     * RtSig limit handling bug
     * Signals leak kernel memory (security) [FIX in ac tree]
     * TTY and N_HDLC layer called poll_wait twice per fd and corrupt
       memory
     * ATM layer calls poll_wait twice per fd and corrupts memory
     * Random calls poll_wait twice per fd and corrupts memory
     * PCI sound calls poll_wait twice per fd and corrupts memory
     * sbus audio calls poll_wait twice per fd and corrupts memory
     * IBM MCA driver breaks on Device_Inquiry at boot
     * SHM code corrupts memory (Russell)
     * Linux sends a 1K buffer with SCSI inquiries. The ANSI-SCSI limit
       is 255.
     * Linux uses TEST_UNIT_READY to chck for device presence on a
       PUN/LUN. The INQUIRY is the only valid test allowed by the spec.
     * truncate_inode_pages does unsafe page cache operations
     * Fix the ptrace code to be back compatible and add a new PTRACE
       call set for getting the PIII extra registers
     * EPIC100 fixes
     * Tlan and Epic100 crash under load
     * Fix hpfs_unlink (Al Viro)
     * exec loader permissions
     * Locking on getcwd
     * E820 memory setup causes crashes/corruption on some laptops[**VERY
       NASTY**] (fixed in test5)
     * Debian report that the gcc 2.95 possibly miscompiles fault.c or
       mm/remap.c (Perl script available from Arjan) (fixed in test2 or
       3)
     * Dcache threading (Al Viro)
     * Sockfs races (removing NULL ->i_sb stuf) (Al Viro)
     * Module remove race bug (done: anything with file_operations, fb
       stuff, procfs stuff - Al Viro)
     * DEFXX driver appears broken (reported fixed by Jeff Garzik)
     * Some FB drivers check the A000 area and find it busy then bomb out
       (checked and fixed, reported by Jeff Garzik)
     * Stick lock_kernel() calls around OSS driver with issues to hard to
       fix nicely for 2.4 itself (Alan, fixed)
     * Merge the current Compaq RAID driver into 2.4 (fixed, reported by
       Thomas Hiller)
     * mount crashes on Alpha platforms (fixed, reported by Thorsten
       Kranzkowski)
     * IDE fails on some VIA boards (eg the i-opener) (reported fixed by
       Konrad Stepien)
     * access_process_mm oops/lockup if task->mm changes (Manfred) [user
       can cause deliberately]
     * PCMCIA IRQ routing should now be fixed modulo ISA cards and bios
       doesn't tell us that an IRQ is ISA-only (Martin Mares)
     * TB Multisound driver hasnt been updated for new isa I/O totally.
       (reported fixed by John Coiner; see
       http://atv.ne.mediaone.net/linux-multisound)
     * yenta (PCMCIA) and pci_socket modules have mutual dependency
       (cardbus_register, yenta_operations) (test5, worked in test3)
       (reported fixed by Erik Mouw)
     * Keyboard/mouse problems (should be fixed?)
     * Floppy driver broken by VFS changes. Other drivers may be too
       (Stuff gets called after _close now - unload race possibly too;
       should be fixed in test6)
     * OSS module remove races (fixed by Christoph Hellwig)
     * Merge the 2.2 ServeRAID driver into 2.4 (Christoph Hellwig)
     * AHA27xx is broken (maybe 28xx too) (reported fixed by Doug
       Ledford)
     * Merge the network fixes (DaveM)
     * Finish 64bit vfs merges (lockf64 and friends missing -- willy?)
       (Andreas Jaeger reports that lockf64 has been added for Intel and
       Alpha; other architectures may not be done, but if not, they won't
       build :-)
     * Can't compile CONFIG_IBMTR and CONFIG_PCMCIA_IBMTR in kernel at
       once; kernel link failes (rasmus; fixed in a kludgy way by not
       allowing the combination by arjan)
     * Merge the RIO driver
     * Potential deadlock in EMU10K driver when running SMP (orre at
       nada.kth.se, Alan)
     * Symbol clashes from ppp and irda compression code (Arjan van de
       Ven)
     * Kernel build has race conditions when building modversions.h
       (Mikael Pettersson)
     * USB Pegasus driver explodes on disconnect (lots of printk and/or
       OOPS spewage to the console. David Ford) (reported fixed by Petko
       Manolov)
     * unsafe sleep_on in ibmcam and ov511 drivers (never was a problem,
       according to Mark McClelland)
     * netfilter doesn't compile correctly (test7-pre3, reported by Pau
       Aliagas, fixed by test7-pre6, rusty)
     * Innd data corruption, probably caused by bug truncation bug (Rik
       van Riel)
     * If all the ISO NLS's are modules, there can be an undefined ref to
       CONFIG_NLS_DEFAULT in inode.c (Dale Amon --- not a bug CONFIG_NLS
       is forced)
     * Fix sysinfo interface so it is binary compatible with 2.2.x (i.e.
       mem_unit=1), except when memory >= 4Gb (Erik Andersen)
     * Some people report 2.3.x serial problems (reported fixed by Shaya
       Potter)
     * Some Ultra-I sbus sparc64 systems fail to boot since 2.4.0-test3,
       may be due to specific memory configurations. (reported fixed by
       davem)
     * Fix, um, interesting races around dup2() and friends. (Al Viro)
     * complete the ext2 races fixes (truncate) (Al Viro)
     * USB pegasus driver doesn't work since 2.4.0test5 (David Ford)
     * Splitting a posix lock causes an infinite loop (Stephen Rothwell,
       according to Rusty)
     * Oops in dquot_transfer (David Ford, Martin Diehl) (Jan Kara has a
       potential patch from 2.2, submitted to Linus by Martin Diehl,
       fixed in test9)
     * SHM segments not always being detached and destroyed right ?
       (problem reported by Lincoln Dale (was combination of XFree86 and
       kernel bug, fixed))
     * Mount of new fs over existing mointpoint should return an error
       unless forced (Andrew McNabb, Alan Cox) (Andries Brouwer has
       posted a patch)
     * Boot hangs on a range of Dell docking stations (Latitude, reported
       fixed in 2.4.0-pre9)
          + Almost certainly related: PCI code doesn't see devices behind
            DECchip 21150 PCI bridges (used in Dell Latitude). Reported
            by Simon Trimmer. (Patch from Martin Mares exists but it
            disables cardbus devices, according to Tigran.)
          + Derek Fawcus at Cisco reports similar problems with Toshiba
            Tecra 8000 attached to the DeskStation V+ docking station.
            (once again, caused by bridge returning 0 when reading the
            I/O base/limit and Memory base/limit registers which confuses
            the new PCI resource code).
     * drivers/sound/cs46xx.c has compile errors test7 and test8 (C
       Sanjayan Rosenmund, reported fixed by Hayden James)
     * Network block device seems broken by block device changes (Jeffrey
       C. Becker reports no problems)
     * cdrecord doesn't work (produces CD-ROM coasters) w/o any errors
       reported, works under 2.2 (Damon LoCascio, reported as fixed by
       Robert M. Love)
     * ACPI hangs on boot for some systems (Are there any cases left?
       Reported as fixed by Simon Richter)
     * arcnet/com20020-isa.c doesn't compile, as of 2.4.0-test8. Dan
       Aloni has a fix, reported fixed)
     * 2.4.0-test8 has a BUG at ll_rw_blk:711. (Johnny Accot, Steffen
       Luitz) (Al Viro has a patch, reported fixed by Udo A. Steinberg)
     * Writing to tapes > 2.4G causes tar to fail with EIO (using
       2.4.0-test7-pre5; it works under 2.4.0-test1-ac18 --- Tigran
       Aivazian, reported fixed)
     * 2.4.0-test2 breaks the behaviour of the ether=0,0,eth1 boot
       parameter (dwguest, reported as fixed.)
     * IBM Thinkpad 390 won't boot since 2.3.11 (Decklin Foster; NOT A
       BUG; caused by misconfigured CPU model)
     * PPC-specific: won't boot on 601 CPU's (powermac) (Andreas Tobler;
       Paul Mackerras has fix in PPC tree)
     * Finish I2O merge (Intel/Alan, reported as fixed as it's going to
       be)
     * Non-atomic page-map operations can cause loss of dirty bit on
       pages (sct, alan, Ben LaHaise fixed)
     * NFS V3 lockd causes kernel oops (Trond Myklebust, reported fixed)
     * VM: Out of Memory handling {CRITICAL} (added in test10)
     * TLAN nic appears to be adding a timer twice (2.4.0test8pre6, Arjan
       ve de Ven) (Fixed, but patch not sent to Linus yet -- Torben
       Mathiasen)
     * Loading the qlogicfc driver in 2.4.0-test8 causes the kernel to
       loop forver reporting SCSI disks that aren't present (Paul
       Hubbard, Torben Mathiasen has a potential patch, sent to Linus,
       need to very with Paul)
     * Fix the minixfs races (Al Viro)
     * SIT tunneling (ipv6 in ipv4) is broken (Gerhard Mack; Davem has a
       fix) (fixed in test10-pre2)
     * USB: hid joystick handling (patch from Vajtech, 2.4.0.9.4)
     * USB: cpia_usb module doesn't handle "no bandwidth" returns (OOPS)
       (2.4.0.9.4)
     * USB: microtek memory handling (patch from Oliver Neukum)
       (2.4.0.9.4)
     * USB: usb-uhci not use set PCI Latency Timer register to 0
     * USB: printer driver aborts on out-of-paper or off-line conditions
       instead of retrying until the condition is fixed
     * USB: usb-uhci SMP spinlock/bad pointer crash
     * USB: cpia camera driver with OHCI HCD locks up or fails
     * USB: pegasus (ethernet) driver crashes often
     * USB: Fix differences in UHCI and OHCI HCD behaviors/semantics:
          + Only uhci.c does EARLY_COMPLETE (drop EARLY_COMPLETE ?)
          + USB: Fix the OOPS in usb-storage from the error-recovery
            handler. {CRITICAL} (reported by Matthew Dharm, fixed as of
            test9)
          + USB: booting with USB compiled into kernel causes a lot of
            syslog entries as the root hubs are probed by all drivers
            (this is especially obnoxious as the usb-serial drivers start
            up) (Fixed in test9, according to Greg KH)
          + USB: fix setting urb->dev in plusb, wacom, mdc800) (Greg KH)
            {CRITICAL} (fixed in test10-pre1)
          + USB: fix usb-uhci setting urb->dev = NULL at correct places
            only {CRITICAL} (fixed in test10-pre1)
          + USB: pegasus driver version 0.4.12: update to work with HCD
            changes; fix module use counting & dev refcounting; fix to
            work with dhcpd (Petko) {CRITICAL} (fixed in test10-pre1)
          + USB: pegasus driver locks up on slow oHCI machine; sometimes
            cannot be rmmod-ed (Cyrille Chepelov) (was uhci problem
            fixedin test10-pre1 according to Petko Manolov)
          + USB: oops on boot with 2.4.0-test9, usb-uhci, pegasus (in
            process_transfer) (frank@unternet.org) (was uhci problem
            fixedin test10-pre1 according to Petko Manolov)
          + Sys_revoke() (CRITICAL, revoke or some subset of it is needed
            to fix some security issues) (alan, linus, worked around for
            now)
          + USB: hotplug (PNP) and module autoloader support (currently
            being tested)
          + USB: OHCI root-hub-timer does not restart on resume
            {CRITICAL} (Paul Mackerras)
          + USB: add bandwidth allocation support to usb-uhci HCD
          + USB: usb-ohci needs to null urb->dev to avoid various
            reboots/hangs/oopses {CRITICAL} (David Brownell)
          + USB: speed up device enumeration (hub driver has large delays
            in it)
          + USB: OOPS when unplugging mouse from external hub (Unable to
            handle kernel paging request at virtual address 00080004; in
            usb_disconnect) (2.4.0-test9-pre7)
          + USB: With uhci HCD, switching from X to a text console and
            back to X, USB mouse is dead. (2.4.0-test9-pre7)
          + USB: plusb oops, segfaults, performance.
          + USB: usb-uhci, microtek scanner driver on 2.4.0-test7 & SANE
            1.0.3 OOPSes; usb-ohci works.
            >[usb-uhci]uhci_cleanup_unlink+4c/140<
          + USB: 2.4.0-test9-pre9: Novatek Ortek USB kbd not working.
          + USB: 2.4.0-test9-pre9: unresolved USB symbols when only
            usbcore is in-kernel.
          + USB: 2.4.0-test10: unresolved symbol 'this_module' when
            compiling only usbcore in kernel (in inode.c).
          + USB: 2.4.0-test9: USB + SMP gives lots of USB device timeout
            errors. OK without SMP. Tyan tiger 133 (1854d, i believe)
            mobo (via apollo pro 133a chipset). Redhat 6.2 and 7.0
            (thought it might be gcc 2.96, but it seems to happen with
            both). Either UHCI HCD. Or Asus p2b-ds mobo with the intel bx
            chipset with same results.
          + USB: test9, test10-pre1, and 2.2.18-pre15: OOPS with USB
            mouse. >>EIP; c0121491 >kmem_cache_free+14d/174< >=====
            Trace; d00387a6 >[usb-uhci]uhci_unlink_urb_sync+122/150<
          + USB: many unexplained "usb_control/bulk_msg: timeout"
            messages on several different USB devices.
          + USB: 3Com USB ISDN TA not working with test9-pre3 or
            test10-pre4. Worked with test8.

Probably Hardware Bugs

     * Data corruption on IDE disks (Generic PCI DMA and SiS support
       Steven Walter) (sounds like PCChips #M599LMR motherboard doesn't
       disable UDMA when a non-UDMA cable is used. If you disable UDMA in
       the BIOS, then there is no problem. hardware bug?)
     * AHA29xx driver appears to stomp other cards (may be BIOS; probably
       motherboard has assigned to small of a range to a card, so that
       it's overlapping with some other card -- Doug Ledford)
     * USB hangs on APM suspend on some machines (fixed more most; Alan
       has one still that fails but the BIOS has 'issues')
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

>      * Palmax PD1100 hangs during boot since 2.4.0-test9 (Alan Cox)

Fixed in pre10.

>      * 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.

>      * 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'

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

and according to Alan

>      * SCSI CD-ROM doesn't work on filesystems with < 2kb block size
>        (Jens Axboe will fix)

SCSI M/O has the same problem. 2.2 can mount MSDOS fs on M/O 2.4test 10 cant.

>      * FAT filesystem doesn't support 2kb sector sizes (did under 2.2.16,
>        doesn't under 2.4.0test7. Kazu Makashima, alan)

This is the same as the SCSI cd rom issue. You can either do reblocking in the
fat layer and other fs's needing it or do it in the scsi code.

>      * Spin doing ioctls on a down netdeice as it unloads == BOOM
>        (prumpf, Alan Cox) Possible other net driver SMP issues (andi
>        kleen)

Turns out to be safe according to Jeff and ANK

> 10. To Do But Non Showstopper
>      * PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is
>        reliable)
>           + PCMCIA crashes on unloading pci_socket

The pci_socket crash is fixed it seems

>      * Some AWE cards are not being found by ISAPnP ??

You have this one higher up as problems with some SB AWE cards

Alan

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

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

[Andi Kleen]

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

It is not safe, just not worse than 2.2.

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

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

[kuznet]

Hello!

> It is not safe, just not worse than 2.2.

Andi...... 8)

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

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

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

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

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

Alan Cox wrote:

> > 10. To Do But Non Showstopper
> >      * PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is
> >        reliable)
> >           + PCMCIA crashes on unloading pci_socket
>
> The pci_socket crash is fixed it seems

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

It uses the ne2k and serial drivers.

-d

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



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 239 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

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

[Jeff Garzik]

David Ford wrote:
> 
> Alan Cox wrote:
> 
> > > 10. To Do But Non Showstopper
> > >      * PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is
> > >        reliable)
> > >           + PCMCIA crashes on unloading pci_socket
> >
> > The pci_socket crash is fixed it seems
> 
> Not unless it was fixed in test10 release.  I have a PC LinkSys dual 10/100 and
> 56K card that will kill the machine if you physically pull it out no matter what
> cardctl/module steps are taken.
> 
> It uses the ne2k and serial drivers.

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

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

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

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

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

-d

Jeff Garzik wrote:

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

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



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 239 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

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

[Jeff Garzik]

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

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

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

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

[Alan Cox]

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

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

> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
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]

Alan Cox wrote:
> 
> > > Not unless it was fixed in test10 release.  I have a PC LinkSys dual 10/100 and
> > > 56K card that will kill the machine if you physically pull it out no matter what
> > > cardctl/module steps are taken.
> > >
> > > It uses the ne2k and serial drivers.
> >
> > Part of that might be that serial doesn't support hotplug without
> > patching.
> 
> Linksys rings a bell with an outstandng 2.2 lockup on pcmcia. I think this might
> be a driver bug ?

On 2.2.x, possibly.

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

	Jeff


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

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

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Alan Cox wrote:

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

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

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

-d

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



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 239 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

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

[tytso]

   Date: Fri, 03 Nov 2000 16:10:50 -0500
   From: Jeff Garzik <jgarzik@mandrakesoft.com>

   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 majordomo@vger.kernel.org
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]

tytso@mit.edu wrote:
> 
>    Date: Fri, 03 Nov 2000 16:10:50 -0500
>    From: Jeff Garzik <jgarzik@mandrakesoft.com>
> 
>    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 majordomo@vger.kernel.org
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]

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.


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

Fixed for a couple versions now.


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

To avoid Andi confusing the issue :) ...

1) The first item listed does not exist

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

	Jeff



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

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

[Paul Gortmaker]

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 <Pine.LNX.4.10.9912281026030.1294-100000@penguin.transmeta.com>
    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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[tytso]

   Date: Fri, 3 Nov 2000 15:53:34 +0000 (GMT)
   From: Alan Cox <alan@lxorguk.ukuu.org.uk>

   >      * 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 majordomo@vger.kernel.org
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]

tytso@mit.edu 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Philipp Rumpf]

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

TBD: sysctl, kernel_thread

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

loop device hangs

[Christian van Enckevort]

> 10. To Do But Non Showstopper
> 
>      * Loop device can still hang (William Stearns has script that will
>        hang 2.4.0-test7, Peter Enderborg has a short sequence that will
>        hang 2.4.0test9)
I think I have the same problem with 2.4.0-test10 (with rieserfs-patch). 
With small images (initrd-ramdisk) I have no problem, but when I prepare an
ext2fs-image for a backup on CD, the system will invariably hang. For me
this is a showstopper bug. I tried to further investigate this bug. I found
it can also be triggered by running bonnie on an ext2fs-image
(filesize=200Mb). When it hung, the EIP pointed to somewhere in
default_idle. Does anybody have some hints for finding some more useful
information about this bug?

Christian van Enckevort
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
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]

tytso@mit.edu wrote:
> 4. Boot Time Failures
> 
>      * Crashes on boot on some Compaqs ? (may be fixed)

compaq laptops?  desktops?  or alphas?


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

Elaboration:  PCI-PCI bridges are not configured correctly

> 5. Compile errors

I doubt you need this category :)


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

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


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

update:  frank davis patch is poor.

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


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

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


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

I thought this was complete a long time ago?


> 8. Fix Exists But Isnt Merged

>      * Many network device drivers don't call MOD_INC_USE_COUNT in
>        dev->open. (Paul Gortmaker has patches)

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


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

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


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

Done.


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

Move to "in progress"...


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

"fall forms"?

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


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

not an issue.


>	Possible other net driver SMP issues (andi
>        kleen)

No showstoppers AFAICS, but small races do exist.


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

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


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

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


>      * kiobuf seperate lock functions/bounce/page_address fixes

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


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

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


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

More than just on reboot.

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

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

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

Jeff Garzik wrote:

> >      * 2.4.0-test8 pcmcia is unusable in fall forms (kernel, mixed, or
> >        dhinds code) (David Ford)
>
> "fall forms"?
>
> David clearly has problems w/ pcmcia, but it is not at all as broken as
> he makes it out to be:  all my cardbus laptops boot and work.
>
>
> >      * PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is
> >        reliable)
>
> Again "whatever".  The CardBus code is definitely usable.  It is not
> mature, but saying it is "basically unusable" is wildly inaccurate.

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

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

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

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

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

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

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

-d


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



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 239 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

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

[Stephen C. Tweedie]

Hi,

On Fri, Nov 03, 2000 at 05:20:53PM -0500, Jeff Garzik wrote:
> 
> >      * kiobuf seperate lock functions/bounce/page_address fixes
> 
> Do Stephen Tweedie's recently posted kiobuf patches fix this issue?

Hopefully, but not 100%: there is still a race window on anonymous
pages which needs to be fixed elsewhere in the VM.  The window for
mmaped files is closed in those patches, though.

--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[tytso]

   Date: Fri, 03 Nov 2000 18:32:31 -0800
   From: David Ford <david@linux.com>

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

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

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

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

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

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

[James Simmons]

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

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

--- vgacon.c.orig	Tue Oct 24 18:45:58 2000
+++ vgacon.c	Tue Oct 24 19:08:51 2000
@@ -46,11 +46,13 @@
 #include <linux/malloc.h>
 #include <linux/vt_kern.h>
 #include <linux/selection.h>
+#include <linux/spinlock.h>
 #include <linux/ioport.h>
 #include <linux/init.h>
 
 #include <asm/io.h>
 
+static spinlock_t vga_lock = SPIN_LOCK_UNLOCKED;
 
 #define BLANK 0x0020
 
@@ -152,8 +154,7 @@
 	 * ddprintk might set the console position from interrupt
 	 * handlers, thus the write has to be IRQ-atomic.
 	 */
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&vga_lock, flags);	
 
 #ifndef SLOW_VGA
 	v1 = reg + (val & 0xff00);
@@ -166,7 +167,7 @@
 	outb_p(reg+1, vga_video_port_reg);
 	outb_p(val & 0xff, vga_video_port_val);
 #endif
-	restore_flags(flags);
+	spin_unlock_irqrestore(&vga_lock, flags);
 }
 
 static const char __init *vgacon_startup(void)
@@ -415,7 +416,7 @@
 	if ((from == lastfrom) && (to == lastto)) return;
 	lastfrom = from; lastto = to;
 
-	save_flags(flags); cli();
+	spin_lock_irqsave(&vga_lock, flags);
 	outb_p(0x0a, vga_video_port_reg);		/* Cursor start */
 	curs = inb_p(vga_video_port_val);
 	outb_p(0x0b, vga_video_port_reg);		/* Cursor end */
@@ -428,7 +429,7 @@
 	outb_p(curs, vga_video_port_val);
 	outb_p(0x0b, vga_video_port_reg);		/* Cursor end */
 	outb_p(cure, vga_video_port_val);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&vga_lock, flags);
 }
 
 static void vgacon_cursor(struct vc_data *c, int mode)
@@ -533,11 +534,11 @@
 {
 	/* save original values of VGA controller registers */
 	if(!vga_vesa_blanked) {
-		cli();
+		spin_lock_irq(&vga_lock);
 		vga_state.SeqCtrlIndex = inb_p(seq_port_reg);
 		vga_state.CrtCtrlIndex = inb_p(vga_video_port_reg);
 		vga_state.CrtMiscIO = inb_p(video_misc_rd);
-		sti();
+		spin_unlock_irq(&vga_lock);
 
 		outb_p(0x00,vga_video_port_reg);	/* HorizontalTotal */
 		vga_state.HorizontalTotal = inb_p(vga_video_port_val);
@@ -561,7 +562,7 @@
 
 	/* assure that video is enabled */
 	/* "0x20" is VIDEO_ENABLE_bit in register 01 of sequencer */
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p(0x01,seq_port_reg);
 	outb_p(vga_state.ClockingMode | 0x20,seq_port_val);
 
@@ -598,13 +599,13 @@
 	/* restore both index registers */
 	outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
 	outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
-	sti();
+	spin_unlock_irq(&vga_lock);
 }
 
 static void vga_vesa_unblank(void)
 {
 	/* restore original values of VGA controller registers */
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p(vga_state.CrtMiscIO,video_misc_wr);
 
 	outb_p(0x00,vga_video_port_reg);		/* HorizontalTotal */
@@ -629,7 +630,7 @@
 	/* restore index/control registers */
 	outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
 	outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
-	sti();
+	spin_unlock_irq(&vga_lock);
 }
 
 static void vga_pal_blank(void)
@@ -750,7 +751,7 @@
 		charmap += 4*cmapsz;
 #endif
 
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p( 0x00, seq_port_reg );   /* First, the sequencer */
 	outb_p( 0x01, seq_port_val );   /* Synchronous reset */
 	outb_p( 0x02, seq_port_reg );
@@ -766,7 +767,7 @@
 	outb_p( 0x00, gr_port_val );    /* disable odd-even addressing */
 	outb_p( 0x06, gr_port_reg );
 	outb_p( 0x00, gr_port_val );    /* map start at A000:0000 */
-	sti();
+	spin_unlock_irq(&vga_lock);
 	
 	if (arg) {
 		if (set)
@@ -793,7 +794,7 @@
 		}
 	}
 	
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p( 0x00, seq_port_reg );   /* First, the sequencer */
 	outb_p( 0x01, seq_port_val );   /* Synchronous reset */
 	outb_p( 0x02, seq_port_reg );
@@ -833,8 +834,7 @@
 		inb_p( video_port_status );
 		outb_p ( 0x20, attrib_port );
 	}
-	sti();
-
+	spin_unlock_irq(&vga_lock);
 	return 0;
 }
 
@@ -865,12 +865,12 @@
 	   registers; they are write-only on EGA, but it appears that they
 	   are all don't care bits on EGA, so I guess it doesn't matter. */
 
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p( 0x07, vga_video_port_reg );		/* CRTC overflow register */
 	ovr = inb_p(vga_video_port_val);
 	outb_p( 0x09, vga_video_port_reg );		/* Font size register */
 	fsr = inb_p(vga_video_port_val);
-	sti();
+	spin_lock_irq(&vga_lock);
 
 	vde = maxscan & 0xff;			/* Vertical display end reg */
 	ovr = (ovr & 0xbd) +			/* Overflow register */
@@ -878,14 +878,14 @@
 	      ((maxscan & 0x200) >> 3);
 	fsr = (fsr & 0xe0) + (fontheight-1);    /*  Font size register */
 
-	cli();
+	spin_lock_irq(&vga_lock);
 	outb_p( 0x07, vga_video_port_reg );		/* CRTC overflow register */
 	outb_p( ovr, vga_video_port_val );
 	outb_p( 0x09, vga_video_port_reg );		/* Font size */
 	outb_p( fsr, vga_video_port_val );
 	outb_p( 0x12, vga_video_port_reg );		/* Vertical display limit */
 	outb_p( vde, vga_video_port_val );
-	sti();
+	spin_unlock_irq(&vga_lock);	
 
 	vc_resize_all(rows, 0);			/* Adjust console size */
 	return 0;



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

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

[Keith Owens]

On Fri, 3 Nov 2000 17:10:52 -0800 (PST), 
James Simmons <jsimmons@suse.com> wrote:
>
>>      * VGA Console can cause SMP deadlock when doing printk {CRITICAL}
>>        (Keith Owens)
>
>Still not fixed :-( Here is the patch again. Keith give it a try and tell
>me if it solves your problems.

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

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

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

[tytso]

   Date: Fri, 3 Nov 2000 17:10:52 -0800 (PST)
   From: James Simmons <jsimmons@suse.com>

   >      * 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Keith Owens]

On Fri, 3 Nov 2000 10:09:31 -0500, 
tytso@mit.edu wrote:
>9. To Do
>     * DRM cannot use AGP support module when CONFIG_MODVERSIONS is
>       defined (issue with get_module_symbol caused fix proposed by John
>       Levon to be rejected)

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

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

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

[Russell King]

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

<aol>
I have a fix likewise for the MTD code, so it builds without CONFIG_MODULES
</aol>
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Woodhouse]

On Sat, 4 Nov 2000, Keith Owens wrote:

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

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

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

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

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

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

-- 
dwmw2


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

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

[Keith Owens]

On Sun, 5 Nov 2000 23:15:27 +0000 (GMT), 
David Woodhouse <dwmw2@infradead.org> wrote:
>Your patch looks like it'll work. Although I don't really see any
>advantage over {get,put}_module_symbol() in this case, it does look like
>it can be used to finally provide module persistent storage, which will be
>useful.

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

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

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

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

[David Woodhouse]

On Mon, 6 Nov 2000, Keith Owens wrote:

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

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

-- 
dwmw2


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

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

[Keith Owens]

On Mon, 6 Nov 2000 00:54:51 +0000 (GMT), 
David Woodhouse <dwmw2@infradead.org> wrote:
>On Mon, 6 Nov 2000, Keith Owens wrote:
>
>> I'm not sure why you think this can be used for module persistent
>> storage.  If a module calls inter_module_register() on load, it should
>> call inter_module_unregister() on unload.  All the registered data
>> points into the loaded module, remove the module and the storage
>> disappears as well.
>
>You can kmalloc() both the im_name and userdata arguments to
>inter_module_register and you ought to be able to pass NULL as the owner.

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

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

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

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

[David Woodhouse]

On Mon, 6 Nov 2000, Keith Owens wrote:

> On Mon, 6 Nov 2000 00:54:51 +0000 (GMT), 
> David Woodhouse <dwmw2@infradead.org> wrote:
> >On Mon, 6 Nov 2000, Keith Owens wrote:
> >
> >> I'm not sure why you think this can be used for module persistent
> >> storage.  If a module calls inter_module_register() on load, it should
> >> call inter_module_unregister() on unload.  All the registered data
> >> points into the loaded module, remove the module and the storage
> >> disappears as well.
> >
> >You can kmalloc() both the im_name and userdata arguments to
> >inter_module_register and you ought to be able to pass NULL as the owner.
> 
> Ughh!  That is definitely abusing the inter_module functions.  If we
> need persistent module storage then we should add a clean interface to
> do it instead of using kmalloc and overloading inter_module_xxx.

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

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

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

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

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

-- 
dwmw2


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

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

[Oliver Xymoron]

On Mon, 6 Nov 2000, Keith Owens wrote:

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

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

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

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

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

[David Woodhouse]

On Mon, 6 Nov 2000, Oliver Xymoron wrote:

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

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

-- 
dwmw2


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

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

[Jeff Garzik]

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

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

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

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

[David Woodhouse]

On Mon, 6 Nov 2000, Jeff Garzik wrote:

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

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


-- 
dwmw2


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

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

[Alan Cox]

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

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

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

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

[Dan Hollis]

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

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

-Dan

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

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

[Jeff Garzik]

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

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

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

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

[Alan Cox]

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

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

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

[Jeff Garzik]

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

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

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

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

[David Woodhouse]

goemon@anime.net said:
>  This is why alsa starts up all devices totally muted. Maybe its time
> for David to move to alsa ;)

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

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

--
dwmw2


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

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

[Jeff Garzik]

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

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

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

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

[Jeff Garzik]

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

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

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

	Jeff


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

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

[David Woodhouse]

jgarzik@mandrakesoft.com said:
>  * Driver initializes mixer to 100% muted * Userspace app sets desired
> values to /dev/mixer * Userspace app opens /dev/dsp to play sound

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


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



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

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

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

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

The inter_module_xxx() stuff would facilitate this quite nicely.

--
dwmw2


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

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

[Jeff Garzik]

David Woodhouse wrote:
> * Sound module is unloaded
> * User continues to happily listen to radio through sound card

You're using the sound card without a driver?


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

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

No kernel coding required.

	Jeff


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

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

[David Woodhouse]

jgarzik@mandrakesoft.com said:
> > * User continues to happily listen to radio through sound card
> You're using the sound card without a driver?

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

jgarzik@mandrakesoft.com said:
>  If you create a post-action in /etc/modules.conf which initializes
> the mixer to proper levels, this problem does not exist.

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

--
dwmw2


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

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

[Jeff Garzik]

David Woodhouse wrote:
> 
> jgarzik@mandrakesoft.com said:
> > > * User continues to happily listen to radio through sound card
> > You're using the sound card without a driver?
> 
> Yes. The sound card allows itself to be unloaded when the pass-through mixer
> levels are non-zero. This is reasonable iff it can be reloaded without
> destroying those levels again.

I don't think that is reasonable.

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

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

	Jeff


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

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

[Alan Cox]

> I don't think that is reasonable.

I think its totally reasonable.

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

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

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

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

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

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

[David Woodhouse]

jgarzik@mandrakesoft.com said:
> > The sound card allows itself to be unloaded when the pass-through
> > mixer levels are non-zero. This is reasonable iff ...

> I don't think that is reasonable. 

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

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

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

jgarzik@mandrakesoft.com said:
> The first thing most drivers do is reset the hardware.   That
> inevitably leads to some sort of blip, when it comes to sound drivers.

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

jgarzik@mandrakesoft.com said:
> You are depending on the hardware to keep its state -between- driver
> unload and driver reload.  That seems inherently unstable to me. 

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

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

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

--
dwmw2


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

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

[Jeff Garzik]

David Woodhouse wrote:
> 
> jgarzik@mandrakesoft.com said:
> > > The sound card allows itself to be unloaded when the pass-through
> > > mixer levels are non-zero. This is reasonable iff ...
> 
> > I don't think that is reasonable.
> 
> You don't think that it's reasonable for the sound card to allow itself to
> be unloaded when the pass-through mixer levels are non-zero?
> 
> So you're suggesting that we should prevent the sound drivers from being
> unloaded at all in that situation?

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


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

Oh, the horror!

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

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


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

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

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

	Jeff


-- 
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Woodhouse]

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

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

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


jgarzik@mandrakesoft.com said:
>  However, since simply leaving the driver loaded solves all this mess,
> it doesn't seem worth changing drivers to do anything different. 

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

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


--
dwmw2


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

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

[David Woodhouse]

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

init_module()
{
	struct mixer_levels *levels;

	levels = inter_module_get("mysoundcard_mixerlevels");

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

	init_hardware(levels);
}

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

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


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


--
dwmw2


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

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

[James A. Sutherland]

On Mon, 06 Nov 2000, David Woodhouse wrote:
> jgarzik@mandrakesoft.com said:
> > > * User continues to happily listen to radio through sound card
> > You're using the sound card without a driver?
> 
> Yes. The sound card allows itself to be unloaded when the pass-through mixer
> levels are non-zero. This is reasonable iff it can be reloaded without 
> destroying those levels again.
> 
> jgarzik@mandrakesoft.com said:
> >  If you create a post-action in /etc/modules.conf which initializes
> > the mixer to proper levels, this problem does not exist.
> 
> Yes it does. It can be a few seconds between initialisation and the 
> post-action running. That's plenty of time to miss what the news announcer 
> was saying about whether you need to go to work today (my gf is a teacher) 
> or to wake the entire house if the mixer levels don't default to zero.

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


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

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Paul Jakma]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Dan Hollis]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

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

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

In your case it would be something like

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

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

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

[James A. Sutherland]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

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

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

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

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

[Petko Manolov]

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


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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Woodhouse]

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

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

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

--
dwmw2


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

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

[James A. Sutherland]

On Mon, 06 Nov 2000, David Woodhouse wrote:
> jas88@cam.ac.uk said:
> >  So autoload the module with a "dont_screw_with_mixer" option. When
> > the kernel first boots, initialise the mixer to suitable settings
> > (load the module with  "do_screw_with_mixer" or whatever); thereafter,
> > the driver shouldn't change the mixer settings on load. 
> 
> Not reliable. You can't read back the current mixer state from all 
> hardware, even if you _are_ willing to assume that it has remained in a 
> sensible state while the driver has been unloaded. 

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

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

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


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

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

[David Woodhouse]

jas88@cam.ac.uk 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.

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

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

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

--
dwmw2


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

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

[Horst von Brand]

David Woodhouse <dwmw2@infradead.org> said:
> jas88@cam.ac.uk 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:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Woodhouse]

vonbrand@inf.utfsm.cl 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alon Ziv]

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" <dwmw2@infradead.org>
To: "Horst von Brand" <vonbrand@inf.utfsm.cl>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, November 06, 2000 19:06
Subject: Re: Persistent module storage [was Linux 2.4 Status / TODO page]


>
> vonbrand@inf.utfsm.cl 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 majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Rogier Wolff]

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. 

-- 
** R.E.Wolff@BitWizard.nl ** 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> > 	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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Woodhouse]

alonz@usa.net 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Tim Riker]

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:
> 
> alonz@usa.net 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 majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

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

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Horst von Brand]

David Woodhouse <dwmw2@infradead.org> said:
> vonbrand@inf.utfsm.cl 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                             vonbrand@sleipnir.valparaiso.cl
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Jamie Lokier]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Martin Dalecki]

Horst von Brand wrote:
> 
> David Woodhouse <dwmw2@infradead.org> said:
> > jas88@cam.ac.uk said:
> > >  Irrelevant. The current mixer settings don't matter: what matters is
> > > that the driver does not change them.
> 
> > It does matter. The sound driver needs to be able to _read_ the current
> > levels. Almost all mixer programs will start by doing this, to set the
> > slider to the correct place.
> 
> OK, how then using _2_ modules, data and worker:

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

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

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

On Mon, 06 Nov 2000, David Woodhouse wrote:
> jas88@cam.ac.uk 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Horst von Brand]

[Chopped down Cc: list]
"James A. Sutherland" <jas88@cam.ac.uk> 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:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

On Mon, 06 Nov 2000, Horst von Brand wrote:
> [Chopped down Cc: list]
> "James A. Sutherland" <jas88@cam.ac.uk> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Horst von Brand]

"James A. Sutherland" <jas88@cam.ac.uk> 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                             vonbrand@sleipnir.valparaiso.cl
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

On Mon, 06 Nov 2000, Horst von Brand wrote:
> "James A. Sutherland" <jas88@cam.ac.uk> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Woodhouse]

jas88@cam.ac.uk 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.


jas88@cam.ac.uk 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

On Mon, 06 Nov 2000, David Woodhouse wrote:
> jas88@cam.ac.uk 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.

> jas88@cam.ac.uk 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Paul Jakma]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Horst von Brand]

David Woodhouse <dwmw2@infradead.org> 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                             vonbrand@sleipnir.valparaiso.cl
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Woodhouse]

jas88@cam.ac.uk 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.


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

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

--
dwmw2


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

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

[James A. Sutherland]

On Mon, 06 Nov 2000, David Woodhouse wrote:
> jas88@cam.ac.uk 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.

> jas88@cam.ac.uk 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Gerhard Mack]

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.
> 
> > jas88@cam.ac.uk 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

gmack@innerfire.net

<>< 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

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.
> > 
> > > jas88@cam.ac.uk 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Gerhard Mack]

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

gmack@innerfire.net

<>< 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Gerhard Mack]

> 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

gmack@innerfire.net

<>< 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Horst von Brand]

"James A. Sutherland" <jas88@cam.ac.uk> 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                             vonbrand@sleipnir.valparaiso.cl
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Woodhouse]

jas88@cam.ac.uk 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. 


jas88@cam.ac.uk 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

On Mon, 06 Nov 2000, David Woodhouse wrote:
> jas88@cam.ac.uk 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.

> jas88@cam.ac.uk 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Evan Jeffrey]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[James A. Sutherland]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Martin Dalecki]

David Woodhouse wrote:
> 
> jgarzik@mandrakesoft.com said:
> >  * Driver initializes mixer to 100% muted * Userspace app sets desired
> > values to /dev/mixer * Userspace app opens /dev/dsp to play sound
> 
> > I don't see where any sound can "escape" in this scenario, and it
> > doesn't require any module data persistence...
> 
> * User boots kernel
> * User loads mixer app
> * Sound module is autoloaded, defaults to zero levels. This is fine.
> * User sets 'line in' level to appropriate level to listen to radio
> * User closes mixer app
> * Time passes
> * Sound module is unloaded
> * User continues to happily listen to radio through sound card
> * Time passes
> * User is listening intently to something on the radio
> * Something wants to beep through /dev/audio
> * Sound module is autoloaded again, default to zero levels.
>         This time it is _NOT_ fine. User is rightly pissed off :)
> 
> It's fine to default to zero levels the first time the sound module is
> loaded after booting. Not on subsequent reloads though.
> 
> A long time ago, I made the sb16 driver use the persistent storage facility
> of kerneld to store mixer levels. I was happy with this right up until
> kerneld disappeared :)

It was removed for good reasons.

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

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

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

[Alan Cox]

> > 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Woodhouse]

alan@lxorguk.ukuu.org.uk 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Oliver Xymoron]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Jeff Garzik]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Oliver Xymoron]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Horst von Brand]

Oliver Xymoron <oxymoron@waste.org> 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                             vonbrand@sleipnir.valparaiso.cl
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Paul Jakma]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Paul Jakma]

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	paul@clubi.ie
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Keith Owens]

On Mon, 6 Nov 2000 23:00:05 +0000 (GMT), 
Paul Jakma <paul@clubi.ie> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Oliver Xymoron]

On Mon, 6 Nov 2000, David Woodhouse wrote:

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

If I understand you correctly:

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

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

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

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

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

[David Woodhouse]

On Mon, 6 Nov 2000, Oliver Xymoron wrote:

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

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

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

'init module' is still _after_ 'set mixer levels'. There is a period
during which the mixer levels are changed.

The desired mixer levels should be available to the module at the time of
initialisation.


-- 
dwmw2


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

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

[Jeff Garzik]

David Woodhouse wrote:
> The desired mixer levels should be available to the module at the time of
> initialisation.

For drivers built into the kernel that gets messy.  The command line is
only so long.  Sounds messy for modules too.  Further (responding to
your other e-mail), few probably care about having the mixer containing
default, not custom, values for 10 seconds between driver init and aumix
execution from initscripts...

It sounds smarter to delay mixer initialization, or mute all mixer
channels at init.  That effectively initializes the mixer channels to
the custom values you desire, without having to add special case module
gunk for the subset of people who need correct mixer values Right
Now(tm).

	Jeff


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

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

[David Woodhouse]

On Mon, 6 Nov 2000, Jeff Garzik wrote:

> David Woodhouse wrote:
> > The desired mixer levels should be available to the module at the time of
> > initialisation.
> 
> For drivers built into the kernel that gets messy.  The command line is
> only so long.  Sounds messy for modules too.  Further (responding to
> your other e-mail), few probably care about having the mixer containing
> default, not custom, values for 10 seconds between driver init and aumix
> execution from initscripts...

I don't mean this to happen on boot. As you say, that gets messy. The
first time a module is loaded after booting, the levels can be all zeroed. 

I'm more interested in the case where the module is loaded for the second
time:

User loads a mixer to set the 'line' level to something sensible so he can
listen to the radio, which is routed through the sound card to his amp.

User closes mixer program. Module is unloaded. Levels remain the same -
all is well.

Some time later, something tries to 'beep' via /dev/audio. Module is
reloaded, the feed the user was listening to is interrupted.

Actually, the way it happened to me was that it was five in the morning, I
was in halls of residence, and suddenly I was playing the radio at full
volume :)

After fixing the sb16 driver to use the existing persistent storage, and
watching that facility disappear from the module support shortly
thereafter, I just decided not to autoload the sound modules.

-- 
dwmw2


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

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

[Andrew Pimlott]

On Mon, Nov 06, 2000 at 08:00:05AM +0000, David Woodhouse wrote:
> I'm more interested in the case where the module is loaded for the second
> time:

Is there really a reason to unload a module in normal usage?  Beyond
miniscule memory savings and hack value?  You can solve the whole
problem with a loud "don't do that".

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Oliver Xymoron]

On Mon, 6 Nov 2000, David Woodhouse wrote:

> On Mon, 6 Nov 2000, Oliver Xymoron wrote:
> 
> > If I understand you correctly:
> > 
> > process 1         process 2
...
> 
> > Is there any reason we ever want to unblock process 1 before process 2
> > terminates?
> 
> No, and I don't think we do. That's not the point.
> 
> 'init module' is still _after_ 'set mixer levels'. There is a period
> during which the mixer levels are changed.

Perhaps you mean before? Otherwise you've lost me.

> The desired mixer levels should be available to the module at the time of
> initialisation.

Is this because active audio sources other than /dev/dsp writers are
suddenly in and out of the mix? If there's nothing on the inputs, it
shouldn't matter whether you're changing the levels.

The right way to do this (according to any sound engineer) is to
initialize all the levels to zero unless told otherwise. This would
doubtless annoy the average user, but is more or less equivalent to not
forwarding packets by default.

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

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

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

[David Woodhouse]

On Mon, 6 Nov 2000, Oliver Xymoron wrote:

> > 'init module' is still _after_ 'set mixer levels'. There is a period
> > during which the mixer levels are changed.
> 
> Perhaps you mean before? Otherwise you've lost me.

Yeah, sorry, not enough coffee yet this morning.

> > The desired mixer levels should be available to the module at the time of
> > initialisation.
> 
> Is this because active audio sources other than /dev/dsp writers are
> suddenly in and out of the mix? If there's nothing on the inputs, it
> shouldn't matter whether you're changing the levels.

Yes. 

> The right way to do this (according to any sound engineer) is to
> initialize all the levels to zero unless told otherwise. This would
> doubtless annoy the average user, but is more or less equivalent to not
> forwarding packets by default.

The current situation is equivalent to stopping forwarding packets each
time an app on the local machine decides it wants to send its own packets,
after a period of inactivity.

Defaulting to zero on boot is fine. Defaulting to zero after the module
has been auto-unloaded and auto-loaded again is less good.

-- 
dwmw2


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

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

[Eric W. Biederman]

David Woodhouse <dwmw2@infradead.org> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Helge Hafting]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Keith Owens]

On 06 Nov 2000 11:09:41 -0700, 
ebiederm@xmission.com (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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[tytso]

   Date: Fri, 03 Nov 2000 17:20:53 -0500
   From: Jeff Garzik <jgarzik@mandrakesoft.com>

   > 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Keith Owens]

On Mon, 06 Nov 2000 07:13:07 -0500, 
Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
>...or, give up this silly nonsense about loading and unload modules on
>every open() and close().   A module load modifies the running kernel
>code... why do people do this on such a whim?
>
>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.

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

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

[Alan Cox]

> >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.

The locking issues are not going to go away. Home PC's are going more and
more USB oriented. Servers are going towards more and more hotswap cards.

Alan

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

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

[Martin Dalecki]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> ...or, give up this silly nonsense about loading and unload modules on
> every open() and close().   A module load modifies the running kernel
> code... why do people do this on such a whim?
> 
> Just load the driver at bootup and forget about it.  Problem solved.

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

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

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

[Paul Jakma]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Martin Mares]

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 <mj@ucw.cz> <mj@suse.cz> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Horst von Brand]

Martin Mares <mj@suse.cz> 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                             vonbrand@sleipnir.valparaiso.cl
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Martin Mares]

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 <mj@ucw.cz> <mj@suse.cz> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Martin Dalecki]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Wayne.Brown]

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 <jas88@cam.ac.uk> on 11/06/2000 11:38:44 AM

To:   Alan Cox <alan@lxorguk.ukuu.org.uk>, jas88@cam.ac.uk (James A. Sutherland)
cc:   dwmw2@infradead.org (David Woodhouse), jgarzik@mandrakesoft.com (Jeff
      Garzik), goemon@anime.net (Dan Hollis), alan@lxorguk.ukuu.org.uk (Alan
      Cox), oxymoron@waste.org (Oliver Xymoron), kaos@ocs.com.au (Keith Owens),
      linux-kernel@vger.kernel.org (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 majordomo@vger.kernel.org
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[David Feuer]

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
David_Feuer@brown.edu

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