ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug,
please don't report it.
Binary searching shows that the bug was introduced by
cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Changes since 2.6.11-rc1-mm2:
linus.patch
bk-acpi.patch
bk-agpgart.patch
bk-alsa.patch
bk-arm.patch
bk-cifs.patch
bk-driver-core.patch
bk-drm.patch
bk-drm-via.patch
bk-i2c.patch
bk-ide-dev.patch
bk-input.patch
bk-dtor-input.patch
bk-netdev.patch
bk-ntfs.patch
bk-scsi-rc-fixes.patch
bk-usb.patch
bk-xfs.patch
Latest versions of various bk trees
-acpi-build-fix-99.patch
-mips-default-mlock-limit-fix.patch
-shared_policy_replace-fix.patch
-generic_file_buffered_write-handle-partial-dio.patch
-cputimeh-seems-to-assume-hz==1000.patch
-ppc32-fix-pmac-kernel-build-with-oprofile.patch
-spinlocking-fixes.patch
-fix-config_agp-depencies.patch
-ioctl-compatibility-for-tiocmiwait-and-tiocgicount.patch
-cls_api-build-fix.patch
-alsa-conversion-to-compat_ioctl-kconfig.patch
-alsa-conversion-to-compat_ioctl-alsa-pcm-api.patch
-alsa-conversion-to-compat_ioctl-alsa-apis.patch
-ac97-audio-support-for-intel-ich7-2611-rc1.patch
-alps-touchpad-detection-fix.patch
-scsi-ncr53c9x-fixes.patch
-uninline-mod_page_state.patch
-fix-audit-control-message-checks.patch
-fix-audit-control-message-checks-tidy.patch
-selinux-add-netlink-message-types-for-the-tc-action-code.patch
-ppc32-update-cpu-state-save-restore.patch
-ppc32-add-missing-prototype.patch
-ppc32-system-platform_device-description-discovery-and-management.patch
-ppc32-infrastructure-changes-to-mpc85xx-sub-arch-from-ocp-to-platform_device.patch
-ppc32-convert-boards-from-using-ocp-to-platform_device.patch
-ppc32-convert-gianfar-ethernet-driver-from-using-an-ocp-to-platform_device.patch
-ppc32-remove-cli-sti-in-arch-ppc-4xx_io-serial_siccc.patch
-ppc32-remove-cli-sti-in-arch-ppc-8xx_io-cs4218_tdmc.patch
-ppc32-remove-cli-sti-in-arch-ppc-8xx_io-fecc.patch
-ppc32-remove-cli-sti-in-arch-ppc-platforms-apus_setupc.patch
-ppc32-remove-cli-sti-in-arch-ppc-platforms-pal4_setupc.patch
-ppc32-remove-cli-sti-in-arch-ppc-syslib-m8xx_setupc.patch
-ppc32-remove-cli-sti-in-arch-ppc-syslib-qspan_pcic.patch
-ppc32-mpc8xx-tlb-miss-vs-tlb-error-fix.patch
-ppc32-update_process_times-simplification.patch
-ppc32-add-defconfigs-for-85xx-boards.patch
-ppc64-remove-config_irq_all_cpus.patch
-ppc64-pci-eeh-documentation.patch
-ppc64-ppc-cleanup-pci-skipping.patch
-ppc64-minimum-hashtable-size.patch
-ppc64-remove-some-unused-iseries-functions.patch
-fix-xenu-kernel-crash-in-dmi_iterate.patch
-x86-use-cpumask_t-instead-of-unsigned-long.patch
-i386-init_intel_cacheinfo-can-be-__init.patch
-arch-i386-kernel-signalc-fix-err-test-twice.patch
-fix-num_online_nodes-warning-on-numa-q.patch
-x86_64-fix-cmp-with-interleaving.patch
-x86_64-fix-flush-race-on-context-switch.patch
-i386-x86-64-fix-smp-nmi-watchdog-race.patch
-x86-64-fix-pud-typo-in-ioremap.patch
-x86-64-fix-do_suspend_lowlevel.patch
-x86-64-clean-up-cpuid-level-detection.patch
-kprobes-x86_64-memory-allocation-changes.patch
-h8-300-defconfig-update.patch
-h8-300-mm-update.patch
-swsusp-remove-on2-algorithm-in-page-relocation.patch
-driver-model-pass-pm_message_t-down-to-pci-drivers.patch
-uml-provide-an-arch-specific-define-for-register-file-size.patch
-uml-provide-some-initcall-definitions-for-userspace-code.patch
-uml-provide-a-release-method-for-the-ubd-driver.patch
-uml-allow-ubd-devices-to-provide-partial-end-blocks.patch
-uml-change-for_each_cpu-to-for_each_online_cpu.patch
-uml-eliminate-unhandled-sigprof-on-halt.patch
-uml-fix-__pud_alloc-definition-to-match-the-declaration.patch
-uml-fix-a-stack-corruption-crash.patch
-uml-define-__have_arch_cmpxchg-on-x86.patch
-file_tableexpand_files-code-cleanup.patch
-file_tableexpand_files-code-cleanup-remove-debug.patch
-minor-ext3-speedup.patch
-move-read-only-and-immutable-checks-into-permission.patch
-factor-out-common-code-around-follow_link-invocation.patch
-radio-typhoon-use-correct-module_param-data-type.patch
-avoid-sparse-warning-due-to-time-interpolator.patch
-allow-all-architectures-to-set-config_debug_preempt.patch
-binfmt_elf-allow-mips-to-overrid-e_flags.patch
-remove-bogus-softirq_pending-usage-in-cris.patch
-switch-frw-to-use-local_soft_irq_pending.patch
-scripts-referencepl-treat-built-ino-as-conglomerate.patch
-vgacon-fixes-to-help-font-restauration-in-x11.patch
-use-official-unicodes-for-dec-vt-characters.patch
-ext3-commit-superblock-before-panicking.patch
-consolidate-arch-specific-resourceh-headers.patch
-use-wno-pointer-sign-for-gcc-40.patch
-fix-init_sighand-warning-on-mips.patch
-add-page_offset-to-mmh.patch
-minor-ipmi-driver-updates.patch
-completion-api-additions.patch
-convert-xfs-to-unlocked_ioctl-and-compat_ioctl.patch
-some-fixes-for-compat-ioctl.patch
-convert-infiniband-mad-driver-to-compat-unlocked_ioctl.patch
-support-compat_ioctl-for-block-devices.patch
-convert-cciss-to-compat_ioctl.patch
-add-compat_ioctl-to-frame-buffer-layer.patch
-convert-sis-fb-driver-to-compat_ioctl.patch
-convert-dv1394-driver-to-compat_ioctl.patch
-convert-video1394-driver-to-compat_ioctl.patch
-convert-amdtp-driver-to-compat_ioctl.patch
-fat-kill-fatfs_symsc.patch
-fat-merge-msdos_fs_isbh-into-msdos_fsh.patch
-fat-is_badchar-is_replacechr-is_skipchar-cleanup.patch
-fat-is_badchar-is_replacechr-is_skipchar-cleanup-cleanup.patch
-fat-return-better-error-codes-from.patch
-fat-manually-inline-shortname_info_to_lcase.patch
-fat-use-vprintk-instead-of-snprintf-with-static.patch
-fat-kill-unnecessary-kmap.patch
-fat-fs-fat-cachec-make-__fat_access-static.patch
-fat-lindent-fs-msdos-nameic.patch
-fat-lindent-fs-vfat-nameic.patch
-fat-lindent-fs-vfat-nameic-fix.patch
-fat-fs-fat-cleanup.patch
-fat-reserved-clusters-cleanup.patch
-fat-show-current-nls-config-even-if-its-default.patch
-lock-initializer-cleanup-ppc.patch
-lock-initializer-cleanup-m32r.patch
-lock-initializer-cleanup-video.patch
-lock-initializer-cleanup-ide.patch
-lock-initializer-cleanup-sound.patch
-lock-initializer-cleanup-sh.patch
-lock-initializer-cleanup-ppc64.patch
-lock-initializer-cleanup-security.patch
-lock-initializer-cleanup-core.patch
-lock-initializer-cleanup-media-drivers.patch
-lock-initializer-cleanup-block-devices.patch
-lock-initializer-cleanup-s390.patch
-lock-initializer-cleanup-usermode.patch
-lock-initializer-cleanup-scsi.patch
-lock-initializer-cleanup-sparc.patch
-lock-initializer-cleanup-v850.patch
-lock-initializer-cleanup-i386.patch
-lock-initializer-cleanup-drm.patch
-lock-initializer-cleanup-firewire.patch
-lock-initializer-cleanup-arm26.patch
-lock-initializer-cleanup-m68k.patch
-lock-initializer-cleanup-network-drivers.patch
-lock-initializer-cleanup-mtd.patch
-lock-initializer-cleanup-x86_64.patch
-lock-initializer-cleanup-filesystems.patch
-lock-initializer-cleanup-ia64.patch
-lock-initializer-cleanup-raid.patch
-lock-initializer-cleanup-isdn.patch
-lock-initializer-cleanup-parisc.patch
-lock-initializer-cleanup-sparc64.patch
-lock-initializer-cleanup-arm.patch
-lock-initializer-cleanup-misc-drivers.patch
-lock-initializer-cleanup-alpha.patch
-lock-initializer-cleanup-character-devices.patch
-lock-initializer-cleanup-drivers-serial.patch
-lock-initializer-cleanup-frv.patch
-typo-in-arch-x86_64-kconfig.patch
Merged
+dib3000mc-build-fix.patch
compile fix
+fbdev-screen-corruption-fix.patch
fbdev screen corruption fix
+mips-fixed-conflicting-types.patch
MIPS build fix
+bug-in-io_destroy-fs-aioc1248.patch
AIO fix
+oprofile-falling-back-on-timer-interrupt-mode.patch
opofile timer-mode fallback fix
+compat-ioctl-security-hook-fixup.patch
Restore missing security hook
-bk-acpi-revert-20041210.patch
Hopefully this is no longer needed
+hda_intel-fix.patch
ALSA build fix
+tpm_msc-build-fix.patch
+tpm_atmel-build-fix.patch
Fix Greg's stuff
+driver-model-more-pm_message_t-conversion.patch
+driver-model-more-pci_choose_states-are-needed.patch
power management/driver model updates
+kbuild-no-redundant-srctree-in-tags-file.patch
`make tags' fix
+mm-oom-killer-tunable.patch
+mm-keep-balance-between-different-classzones.patch
+mm-fix-several-oom-killer-bugs.patch
+mm-convert-memdie-to-an-atomic-thread-bitflag.patch
+make-used_math-smp-safe.patch
+mm-adjust-dirty-threshold-for-lowmem-only-mappings.patch
+mm-truncate-smp-race-fix.patch
Various page allocator and oom killer fixes/updates
+simpler-topdown-mmap-layout-allocator.patch
Simplify the virtual address layout logic
+alloc_zeroed_user_highpage-to-fix-the-clear_user_highpage-issue.patch
Fix clear_user_highpage on architectures with funky caches
+smc91x-power-down-phy-on-suspend.patch
+e100-locking-up-netconsole.patch
net driver fixes
+ppc32-add-defconfigs-for-85xx-boards-updated.patch
ppc32 defconfig updates
+ppc32-allow-usage-of-gen550-on-platforms-that-do-not-define.patch
+ppc32-missing-call-to-ioremap-in-pci_iomap.patch
+ppc32-fix-pci2-io-space-mapping-on-cds.patch
+ppc32-add-support-for-pegasos-machines.patch
ppc32 updates
+ppc64-limit-segment-tables-on-up-kernels.patch
+ppc64-xmon-data-breakpoints-on-partitioned-systems.patch
+ppc64-fix-in_be64-definition.patch
+ppc64-clear-msr_ri-earlier-in-syscall-exit-path.patch
+ppc64-replace-schedule_timeout-in-iseries_pci_reset.patch
+ppc64-replace-schedule_timeout-in-pseries_cpu_die.patch
+ppc64-replace-schedule_timeout-in-__cpu_up.patch
+ppc64-replace-schedule_timeout-in-die.patch
+ppc64-trivial-cleanup-eeh_region.patch
+ppc64-sparse-fixes-for-cpu-feature-constants.patch
+ppc64-use-kref-for-device_node-refcounting.patch
+ppc64-allow-eeh-to-be-disabled.patch
+ppc64-disable-some-boot-wrapper-debug.patch
+ppc64-problem-disabling-sysvipc.patch
+ppc64-enable-virtual-ethernet-and-virtual-scsi.patch
ppc64 updates
+x86-remove-unused-function.patch
cleanup
+x86_64-remove-centaur-mtrr-support.patch
+x86_64-remove-duplicated-includes.patch
+x86_64-enlarge-northbridge-numa-scan-mask.patch
+x86_64-remove-earlyprintk-help.patch
+x86_64-speed-up-suspend.patch
x86_64 update
+h8300-fix-warning.patch
+h8300-makefile-update.patch
H8/300 updates
+swsusp-comment-fix.patch
Fix a comment
+kill-softirq_pending-fix.patch
Remove softirq_pending()
+ext2-ext3-block-allocator-startup-fix.patch
Fix ext2/ext3 block allocator buglet
+ext3-quota-leak-fix.patch
Fix error-path quota leak
+ext3-fix-ea-in-inode-default-acl-creation.patch
+ext2-ext3-acls-remove-the-number-of-acl-entries-limit.patch
EA/ACL fixes
+jbd-journal-overflow-fix.patch
+jbd-journal-overflow-fix-fixes.patch
+jbd-fix-against-journal-overflow.patch
+jbd-fix-against-journal-overflow-tidies.patch
+jbd-log-space-management-optimization.patch
Various JBD corner-case fixes
+i4l-new-hfc_usb-driver-version.patch
+i4l-hfc-4s-and-hfc-8s-driver.patch
i4l updates
+i810_audio-offset-lvi-from-civ-to-avoid-stalled-start.patch
Audio driver fix
+configurable-delay-before-mounting-root-device.patch
Add `delay=' boot option
+fs-mbcachec-remove-an-unused-wait-queue-variable.patch
Dead code
+device-mapper-fix-mirror-log-type-module-ref-count.patch
+device-mapper-remove-unused-bs_bio_init.patch
+device-mapper-add-presuspend-hook.patch
+device-mapper-optionally-bypass-a-bdget.patch
+device-mapper-fix-tb-stripe-data-corruption.patch
DM updates
+arm26-new-maintainer-of-archimedes-floppy-and-hard-disk-drivers.patch
MAINTAINERS update
+problems-disabling-sysctl.patch
Add sys32_sysctl stub
+genhd-rename-device_init.patch
Namespace cleanup
+fix-race-between-the-nmi-code-and-the-cmos-clock.patch
Fix race between concurrent accesses to the x86 CMOS chip
+infiniband-core-compat_ioctl-conversion-minor-fixes.patch
+infiniband-mthca-more-arbel-mem-free-support.patch
+infiniband-mthca-implement-modifying-port-attributes.patch
+infiniband-core-fix-port-capability-enums-bit-order.patch
+infiniband-mthca-dont-write-ecr-in-msi-x-mode.patch
+infiniband-mthca-pass-full-process_mad-info-to-firmware.patch
+infiniband-mthca-optimize-event-queue-handling.patch
+infiniband-mthca-test-irq-routing-during-initialization.patch
+infiniband-ipoib-remove-uses-of-yield.patch
+infiniband-core-add-issm-userspace-support.patch
+infiniband-mthca-clean-up-ioremap-request_region-usage.patch
+infiniband-mthca-remove-x86-sse-pessimization.patch
infiniband updates
+random-pt4-create-new-rol32-ror32-bitops.patch
+random-pt4-use-them-throughout-the-tree.patch
+random-pt4-kill-the-sha-variants.patch
+random-pt4-cleanup-sha-interface.patch
+random-pt4-move-sha-code-to-lib.patch
+random-pt4-replace-sha-with-faster-version.patch
+random-pt4-replace-sha-with-faster-version-fix.patch
+random-pt4-update-cryptolib-to-use-sha-fro-lib.patch
+random-pt4-move-halfmd4-to-lib.patch
+random-pt4-kill-duplicate-halfmd4-in-ext3-htree.patch
+random-pt4-kill-duplicate-halfmd4-in-ext3-htree-fix.patch
+random-pt4-simplify-and-shrink-syncookie-code.patch
+random-pt4-move-syncookies-to-net.patch
+random-pt4-move-other-tcp-ip-bits-to-net.patch
More random driver slash-and-burn
+posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
+posix-timers-high-resolution-cpu-clocks-for-posix-clock_-syscalls.patch
+posix-timers-fix-posix-timers-signals-lock-order.patch
+posix-timers-cpu-clock-support-for-posix-timers.patch
+make-itimer_real-per-process.patch
+make-itimer_prof-itimer_virtual-per-process.patch
+make-rlimit_cpu-sigxcpu-per-process.patch
Bunch of timekeeping updates, including per-thread cpu clocks. Needs a
patched glibc to test it.
+mips-fixed-ltt-build-errors.patch
+ltt-doesnt-build-on-x86_64.patch
Fix ltt-induced MIPS build errors
+nfsacl-protocol-extension-for-nfsv3.patch
+nfsacl-return-enosys-for-rpc-programs-that-are-unavailable.patch
+nfsacl-add-missing-eopnotsupp-=-nfs3err_notsupp-mapping-in-nfsd.patch
+nfsacl-allow-multiple-programs-to-listen-on-the-same-port.patch
+nfsacl-allow-multiple-programs-to-share-the-same-transport.patch
+nfsacl-lazy-rpc-receive-buffer-allocation.patch
+nfsacl-encode-and-decode-arbitrary-xdr-arrays.patch
+nfsacl-encode-and-decode-arbitrary-xdr-arrays-fix.patch
+nfsacl-add-noacl-nfs-mount-option.patch
+nfsacl-infrastructure-and-server-side-of-nfsacl.patch
+nfsacl-solaris-nfsacl-workaround.patch
+nfsacl-client-side-of-nfsacl.patch
+nfsacl-acl-umask-handling-workaround-in-nfs-client.patch
+nfsacl-cache-acls-on-the-nfs-client-side.patch
ACLs for ther NFS client.
-jbd-remove-livelock-avoidance.patch
Dropped - this optimisation was never right and I lost interest in it.
+sched-account-rt_tasks-as-iso_ticks.patch
SCHED_ISO fix
+videotext-ioctls-changed-to-use-_io-macros.patch
+video-arv-remove-casts.patch
+video-w9966-remove-casts.patch
+video-zr36120-remove-casts.patch
+v4l-video-buf-update.patch
+v4l2-tuner-api-update.patch
+v4l-tuner-update.patch
+v4l-add-tveeprom-module.patch
+v4l-tvaudio-update.patch
+v4l-bttv-ir-input-driver-update.patch
+v4l-bttv-update.patch
+v4l-saa7134-module.patch
v4l updates.
+crashdump-reserving-backup-region-for-kexec-based.patch
crashdump-via-kexec update
+fix-architecture-names-in-hugetlbpagetxt.patch
Documentation fix
+fuse-fix-llseek-on-device.patch
FUSE fix
+kernel-configsc-make-a-variable-static.patch
+kernel-forkc-make-mm_cachep-static.patch
+kernel-kallsymsc-make-some-code-static.patch
+mm-page-writebackc-remove-an-unused-function.patch
+mm-shmemc-make-a-struct-static.patch
+make-loglevels-in-init-mainc-a-little-more-sane.patch
+isicom-use-null-for-pointer.patch
+remove-bouncing-email-address-of-hennus-bergman.patch
+cirrusfbc-make-some-code-static.patch
+matroxfb_basec-make-some-code-static.patch
+asiliantfbc-make-some-code-static.patch
+i386-apic-kconfig-cleanups.patch
+security-seclvlc-make-some-code-static.patch
+drivers-block-elevatorc-make-two-functions-static.patch
+drivers-block-rdc-make-two-variables-static.patch
+loopc-make-two-functions-static.patch
+remove-bouncing-email-address-of-thomas-hood.patch
+fs-adfs-dir_fc-remove-an-unused-function.patch
+drivers-char-moxac-if-0-an-unused-function.patch
Little fixes.
number of patches in -mm: 534
number of changesets in external trees: 386
number of patches in -mm only: 517
total patches: 903
All 534 patches:
linus.patch
dib3000mc-build-fix.patch
dib3000mc build fix
fbdev-screen-corruption-fix.patch
fbdev: screen corruption fix
mips-fixed-conflicting-types.patch
mips: fixed conflicting types
bug-in-io_destroy-fs-aioc1248.patch
Fix BUG in io_destroy
oprofile-falling-back-on-timer-interrupt-mode.patch
oprofile: falling back on timer interrupt mode
compat-ioctl-security-hook-fixup.patch
compat ioctl security hook fixup
ia64-acpi-build-fix.patch
ia64 acpi build fix
ia64-config_apci_numa-fix.patch
ia64 CONFIG_APCI_NUMA fix
bk-acpi.patch
acpi-sleep-while-atomic-during-s3-resume-from-ram.patch
acpi: sleep-while-atomic during S3 resume from ram
acpi-report-errors-in-fanc.patch
ACPI: report errors in fan.c
acpi-flush-tlb-when-pagetable-changed.patch
acpi: flush TLB when pagetable changed
acpi-kfree-fix.patch
a
bk-agpgart.patch
bk-alsa.patch
hda_intel-fix.patch
hda_intel macro expansion fix
bk-arm.patch
bk-cifs.patch
bk-driver-core.patch
tpm_msc-build-fix.patch
tpm_msc-build-fix
tpm_atmel-build-fix.patch
tpm_atmel build fix
driver-model-more-pm_message_t-conversion.patch
driver model: more pm_message_t conversion
driver-model-more-pci_choose_states-are-needed.patch
driver model: more pci_choose_state()s are needed
bk-drm.patch
bk-drm-via.patch
bk-i2c.patch
bk-ide-dev.patch
ide-dev-build-fix.patch
ide-dev-build-fix
bk-input.patch
disable-sidewinder-debug-messages.patch
Disable Sidewinder debug messages
bk-dtor-input.patch
kbuild-no-redundant-srctree-in-tags-file.patch
kbuild: no redundant srctree in tags file
seagate-st3200822as-sata-disk-needs-to-be-in-sil_blacklist-as-well.patch
Seagate ST3200822AS SATA disk needs to be in sil_blacklist as well
bk-netdev.patch
bk-ntfs.patch
prevent-pci_name_bus-buffer-overflows.patch
prevent pci_name_bus() buffer overflows
maintainers-add-entry-for-qla2xxx-driver.patch
MAINTAINERS: add entry for qla2xxx driver.
bk-scsi-rc-fixes.patch
bk-usb.patch
bk-xfs.patch
mm.patch
add -mmN to EXTRAVERSION
fix-smm-failures-on-e750x-systems.patch
fix SMM failures on E750x systems
mm-oom-killer-tunable.patch
mm: oom-killer tunable
mm-keep-balance-between-different-classzones.patch
mm: rework lower-zone protection initialisation
mm-fix-several-oom-killer-bugs.patch
mm: fix several oom killer bugs
mm-convert-memdie-to-an-atomic-thread-bitflag.patch
mm: convert memdie to an atomic thread bitflag
make-used_math-smp-safe.patch
make used_math SMP-safe
mm-adjust-dirty-threshold-for-lowmem-only-mappings.patch
mm: adjust dirty threshold for lowmem-only mappings
mm-truncate-smp-race-fix.patch
mm: truncate SMP race fix
vm-pageout-throttling.patch
vm: pageout throttling
orphaned-pagecache-memleak-fix.patch
orphaned pagecache memleak fix
swapspace-layout-improvements.patch
swapspace-layout-improvements
simpler-topdown-mmap-layout-allocator.patch
simpler topdown mmap layout allocator
alloc_zeroed_user_highpage-to-fix-the-clear_user_highpage-issue.patch
alloc_zeroed_user_highpage() to fix the clear_user_highpage issue
make-tree_lock-an-rwlock.patch
make mapping->tree_lock an rwlock
must-fix.patch
must fix lists update
must fix list update
mustfix update
must-fix update
mustfix lists
pcnet32-79c976-with-fiber-optic.patch
pcnet32: 79c976 with fiber optic fix
add-omap-support-to-smc91x-ethernet-driver.patch
Add OMAP support to smc91x Ethernet driver
b44-bounce-buffer-fix.patch
b44 bounce buffering fix
netpoll-fix-napi-polling-race-on-smp.patch
netpoll: fix NAPI polling race on SMP
tun-tan-arp-monitor-support.patch
tun/tap ARP monitor support
atmel_cs-add-support-lg-lw2100n-wlan-pcmcia-card.patch
atmel_cs: Add support LG LW2100N WLAN PCMCIA card
smc91x-power-down-phy-on-suspend.patch
smc91x: power down PHY on suspend
e100-locking-up-netconsole.patch
e100 locking up netconsole.
ppc32-add-defconfigs-for-85xx-boards-updated.patch
ppc32: Add defconfigs for 85xx boards -- updated
ppc32-pmac-sleep-support-update.patch
ppc32: pmac sleep support update
add-try_acquire_console_sem.patch
Add try_acquire_console_sem
update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch
update aty128fb sleep/wakeup code for new powermac changes
radeonfb-massive-update-of-pm-code.patch
radeonfb: massive update of PM code
radeonfb-build-fix.patch
radeonfb-build-fix
ppc32-allow-usage-of-gen550-on-platforms-that-do-not-define.patch
ppc32: allow usage of gen550 on platforms that do not define SERIAL_PORT_DFNS
ppc32-missing-call-to-ioremap-in-pci_iomap.patch
ppc32: missing call to ioremap in pci_iomap()
ppc32-fix-pci2-io-space-mapping-on-cds.patch
ppc32: fix PCI2 IO space mapping on CDS
ppc32-add-support-for-pegasos-machines.patch
ppc32: Add support for Pegasos machines
ppc64-limit-segment-tables-on-up-kernels.patch
ppc64: limit segment tables on UP kernels
ppc64-xmon-data-breakpoints-on-partitioned-systems.patch
ppc64: xmon data breakpoints on partitioned systems
ppc64-fix-in_be64-definition.patch
ppc64: fix in_be64 definition
ppc64-clear-msr_ri-earlier-in-syscall-exit-path.patch
ppc64: clear MSR_RI earlier in syscall exit path
ppc64-replace-schedule_timeout-in-iseries_pci_reset.patch
ppc64: replace schedule_timeout in iSeries_pci_reset
ppc64-replace-schedule_timeout-in-pseries_cpu_die.patch
ppc64: replace schedule_timeout in pSeries_cpu_die
ppc64-replace-schedule_timeout-in-__cpu_up.patch
ppc64: replace schedule_timeout in __cpu_up
ppc64-replace-schedule_timeout-in-die.patch
ppc64: replace schedule_timeout in die
ppc64-trivial-cleanup-eeh_region.patch
ppc64: trivial cleanup: EEH_REGION
ppc64-sparse-fixes-for-cpu-feature-constants.patch
ppc64: sparse fixes for cpu feature constants
ppc64-use-kref-for-device_node-refcounting.patch
ppc64: use kref for device_node refcounting
ppc64-allow-eeh-to-be-disabled.patch
ppc64: allow EEH to be disabled
ppc64-disable-some-boot-wrapper-debug.patch
ppc64: disable some boot wrapper debug
ppc64-problem-disabling-sysvipc.patch
ppc64: problem disabling SYSVIPC
ppc64-enable-virtual-ethernet-and-virtual-scsi.patch
ppc64: enable virtual ethernet and virtual scsi
ppc64-reloc_hide.patch
agpgart-allow-multiple-backends-to-be-initialized.patch
agpgart: allow multiple backends to be initialized
agpgart-allow-multiple-backends-to-be-initialized fix
agpgart: add bridge assignment missed in agp_allocate_memory
x86_64 agp failure fix
agpgart-add-agp_find_bridge-function.patch
agpgart: add agp_find_bridge function
agpgart-allow-drivers-to-allocate-memory-local-to.patch
agpgart: allow drivers to allocate memory local to the bridge
drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch
drm: add support for new multiple agp bridge agpgart api
fb-add-support-for-new-multiple-agp-bridge-agpgart-api.patch
fb: add support for new multiple agp bridge agpgart api
agpgart-add-bridge-parameter-to-driver-functions.patch
agpgart: add bridge parameter to driver functions
superhyway-bus-support.patch
SuperHyway bus support
x86-no-interrupts-from-secondary-cpus-until-officially-online.patch
x86: no interrupts from secondary CPUs until officially online
x86-remove-unused-function.patch
x86: Remove unused function
x86_64-remove-centaur-mtrr-support.patch
x86_64: remove centaur mtrr support
x86_64-remove-duplicated-includes.patch
x86_64: remove duplicated includes
x86_64-enlarge-northbridge-numa-scan-mask.patch
x86_64: Enlarge northbridge numa scan mask
x86_64-remove-earlyprintk-help.patch
x86_64: Remove earlyprintk help
x86_64-speed-up-suspend.patch
x86_64: Speed up suspend
xen-vmm-4-add-ptep_establish_new-to-make-va-available.patch
Xen VMM #4: add ptep_establish_new to make va available
xen-vmm-4-return-code-for-arch_free_page.patch
Xen VMM #4: return code for arch_free_page
xen-vmm-4-return-code-for-arch_free_page-fix.patch
Get rid of arch_free_page() warning
xen-vmm-4-runtime-disable-of-vt-console.patch
Xen VMM #4: runtime disable of VT console
xen-vmm-4-has_arch_dev_mem.patch
Xen VMM #4: HAS_ARCH_DEV_MEM
xen-vmm-4-split-free_irq-into-teardown_irq.patch
Xen VMM #4: split free_irq into teardown_irq
h8300-fix-warning.patch
h8300: fix warning
h8300-makefile-update.patch
h8300: makefile update
swsusp-comment-fix.patch
swsusp: fix buggy comment
wacom-tablet-driver.patch
wacom tablet driver
force-feedback-support-for-uinput.patch
Force feedback support for uinput
kmap_atomic-takes-char.patch
kmap_atomic takes char*
kmap_atomic-takes-char-fix.patch
kmap_atomic-takes-char-fix
kmap_atomic-fallout.patch
kmap_atomic fallout
kunmap-fallout-more-fixes.patch
kunmap-fallout-more-fixes
make-sysrq-f-call-oom_kill.patch
make sysrq-F call oom_kill()
allow-admin-to-enable-only-some-of-the-magic-sysrq-functions.patch
Allow admin to enable only some of the Magic-Sysrq functions
sort-out-pci_rom_address_enable-vs-ioresource_rom_enable.patch
Sort out PCI_ROM_ADDRESS_ENABLE vs IORESOURCE_ROM_ENABLE
irqpoll.patch
irqpoll
poll-mini-optimisations.patch
poll: mini optimisations
mtrr-size-and-base-debug.patch
mtrr size-and-base debugging
cleanup-vc-array-access.patch
cleanup vc array access
remove-console_macrosh.patch
remove console_macros.h
merge-vt_struct-into-vc_data.patch
merge vt_struct into vc_data
kill-softirq_pending.patch
kill softirq_pending()
kill-softirq_pending-fix.patch
kill-softirq_pending fix
clean-up-uts_release-usage.patch
clean up UTS_RELEASE usage
3c59x-ethtool-provide-nic-specific-stats.patch
3c59x ethtool: provide NIC-specific stats
ext2-ext3-block-allocator-startup-fix.patch
ext2/ext3: block allocator startup fix
ext3-quota-leak-fix.patch
ext3: fix error-path quota leak
ext3-ea-no-lock-needed-when-freeing-inode.patch
ext3/ea: no lock needed when freeing inode
ext3-ea-set-the-ext3_feature_compat_ext_attr-for-in-inode-xattrs.patch
ext3/ea: set the EXT3_FEATURE_COMPAT_EXT_ATTR for in-inode xattrs
ext3-ea-documentation-fix.patch
ext3/ea: documentation fix
ext3-ea-fix-i_extra_isize-check.patch
ext3/ea: ix i_extra_isize check
ext3-ea-disallow-in-inode-attributes-for-reserved-inodes.patch
ext3/ea: disallow in-inode attributes for reserved inodes
ext3-fix-ea-in-inode-default-acl-creation.patch
ext3: fix ea-in-inode default ACL creation
ext2-ext3-acls-remove-the-number-of-acl-entries-limit.patch
ext2/ext3 ACLs: remove the number of acl entries limit
jbd-journal-overflow-fix.patch
JBD: journal overflow fix
jbd-journal-overflow-fix-fixes.patch
jbd-journal-overflow-fix-fixes
jbd-fix-against-journal-overflow.patch
JBD: fix against journal overflow
jbd-fix-against-journal-overflow-tidies.patch
jbd-fix-against-journal-overflow-tidies
jbd-log-space-management-optimization.patch
JBD: log space management optimization
i4l-new-hfc_usb-driver-version.patch
i4l: new hfc_usb driver version
i4l-hfc-4s-and-hfc-8s-driver.patch
i4l: HFC-4S and HFC-8S driver
i810_audio-offset-lvi-from-civ-to-avoid-stalled-start.patch
i810_audio: offset LVI from CIV to avoid stalled start
configurable-delay-before-mounting-root-device.patch
Configurable delay before mounting root device
fs-mbcachec-remove-an-unused-wait-queue-variable.patch
fs/mbcache.c: Remove an unused wait queue variable
device-mapper-fix-mirror-log-type-module-ref-count.patch
device-mapper: fix mirror log type module ref count
device-mapper-remove-unused-bs_bio_init.patch
device-mapper: remove unused bs_bio_init()
device-mapper-add-presuspend-hook.patch
device-mapper: Add presuspend hook
device-mapper-optionally-bypass-a-bdget.patch
device-mapper: optionally bypass a bdget
device-mapper-fix-tb-stripe-data-corruption.patch
device-mapper: fix TB stripe data corruption
arm26-new-maintainer-of-archimedes-floppy-and-hard-disk-drivers.patch
arm26: new maintainer of Archimedes floppy and hard disk drivers
problems-disabling-sysctl.patch
Problems disabling SYSCTL
genhd-rename-device_init.patch
genhd: rename device_init
fix-race-between-the-nmi-code-and-the-cmos-clock.patch
Fix race between the NMI code and the CMOS clock
infiniband-core-compat_ioctl-conversion-minor-fixes.patch
InfiniBand/core: compat_ioctl conversion minor fixes
infiniband-mthca-more-arbel-mem-free-support.patch
InfiniBand/mthca: more Arbel Mem-Free support
infiniband-mthca-implement-modifying-port-attributes.patch
InfiniBand/mthca: implement modifying port attributes
infiniband-core-fix-port-capability-enums-bit-order.patch
InfiniBand/core: fix port capability enums bit order
infiniband-mthca-dont-write-ecr-in-msi-x-mode.patch
InfiniBand/mthca: don't write ECR in MSI-X mode
infiniband-mthca-pass-full-process_mad-info-to-firmware.patch
InfiniBand/mthca: pass full process_mad info to firmware
infiniband-mthca-optimize-event-queue-handling.patch
InfiniBand/mthca: optimize event queue handling
infiniband-mthca-test-irq-routing-during-initialization.patch
InfiniBand/mthca: test IRQ routing during initialization
infiniband-ipoib-remove-uses-of-yield.patch
InfiniBand/ipoib: remove uses of yield()
infiniband-core-add-issm-userspace-support.patch
InfiniBand/core: add IsSM userspace support
infiniband-mthca-clean-up-ioremap-request_region-usage.patch
InfiniBand/mthca: clean up ioremap()/request_region() usage
infiniband-mthca-remove-x86-sse-pessimization.patch
InfiniBand/mthca: remove x86 SSE pessimization
random-pt2-cleanup-waitqueue-logic-fix-missed-wakeup.patch
random: cleanup waitqueue logic, fix missed wakeup
random-pt2-kill-pool-clearing.patch
random: kill pool clearing
random-pt2-combine-legacy-ioctls.patch
random: combine legacy ioctls
random-pt2-re-init-all-pools-on-zero.patch
random: re-init all pools on zero
random-pt2-simplify-initialization.patch
random: simplify initialization
random-pt2-kill-memsets-of-static-data.patch
random: kill memsets of static data
random-pt2-kill-dead-extract_state-struct.patch
random: kill dead extract_state struct
random-pt2-kill-22-compat-waitqueue-defs.patch
random: kill 2.2 compat waitqueue defs
random-pt2-kill-redundant-rotate_left-definitions.patch
random: kill redundant rotate_left definitions
random-pt2-kill-misnamed-log2.patch
random: kill misnamed log2
random-pt3-more-meaningful-pool-names.patch
random: More meaningful pool names
random-pt3-static-allocation-of-pools.patch
random: Static allocation of pools
random-pt3-static-sysctl-bits.patch
random: Static sysctl bits
random-pt3-catastrophic-reseed-checks.patch
random: Catastrophic reseed checks
random-pt3-entropy-reservation-accounting.patch
random: Entropy reservation accounting
random-pt3-reservation-flag-in-pool-struct.patch
random: Reservation flag in pool struct
random-pt3-reseed-pointer-in-pool-struct.patch
random: Reseed pointer in pool struct
random-pt3-break-up-extract_user.patch
random: Break up extract_user
random-pt3-remove-dead-md5-copy.patch
random: Remove dead MD5 copy
random-pt3-simplify-hash-folding.patch
random: Simplify hash folding
random-pt3-clean-up-hash-buffering.patch
random: Clean up hash buffering
random-pt3-remove-entropy-batching.patch
random: Remove entropy batching
random-pt4-create-new-rol32-ror32-bitops.patch
random: Create new rol32/ror32 bitops
random-pt4-use-them-throughout-the-tree.patch
random: Use them throughout the tree
random-pt4-kill-the-sha-variants.patch
random: Kill the SHA variants
random-pt4-cleanup-sha-interface.patch
random: Cleanup SHA interface
random-pt4-move-sha-code-to-lib.patch
random: Move SHA code to lib/
random-pt4-replace-sha-with-faster-version.patch
random: Replace SHA with faster version
random-pt4-replace-sha-with-faster-version-fix.patch
random-pt4-replace-sha-with-faster-version-fix
random-pt4-update-cryptolib-to-use-sha-fro-lib.patch
random: Update cryptolib to use SHA fro lib
random-pt4-move-halfmd4-to-lib.patch
random: Move halfmd4 to lib
random-pt4-kill-duplicate-halfmd4-in-ext3-htree.patch
random: Kill duplicate halfmd4 in ext3 htree
random-pt4-kill-duplicate-halfmd4-in-ext3-htree-fix.patch
random-pt4-kill-duplicate-halfmd4-in-ext3-htree-fix
random-pt4-simplify-and-shrink-syncookie-code.patch
random: Simplify and shrink syncookie code
random-pt4-move-syncookies-to-net.patch
random: Move syncookies to net/
random-pt4-move-other-tcp-ip-bits-to-net.patch
random: Move other tcp/ip bits to net/
speedup-proc-pid-maps.patch
Speed up /proc/pid/maps
speedup-proc-pid-maps-fix.patch
Speed up /proc/pid/maps fix
speedup-proc-pid-maps-fix-fix.patch
speedup-proc-pid-maps fix fix
speedup-proc-pid-maps-fix-fix-fix.patch
speedup /proc/<pid>/maps(4th version)
fix-loss-of-records-on-size-4096-in-proc-pid-maps.patch
fix loss of records on size > 4096 in proc/<pid>/maps
speedup-proc-pid-maps-fix-fix-fix-fix.patch
speedup-proc-pid-maps-fix-fix-fix fix
inotify.patch
inotify
posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
posix-timers: tidy up clock interfaces and consolidate dispatch logic
posix-timers-high-resolution-cpu-clocks-for-posix-clock_-syscalls.patch
posix-timers: high-resolution CPU clocks for POSIX clock_* syscalls
posix-timers-fix-posix-timers-signals-lock-order.patch
posix-timers: fix posix-timers signals lock order
posix-timers-cpu-clock-support-for-posix-timers.patch
posix-timers: CPU clock support for POSIX timers
make-itimer_real-per-process.patch
make ITIMER_REAL per-process
make-itimer_prof-itimer_virtual-per-process.patch
make ITIMER_PROF, ITIMER_VIRTUAL per-process
make-rlimit_cpu-sigxcpu-per-process.patch
make RLIMIT_CPU/SIGXCPU per-process
relayfs-doc.patch
relayfs: doc
relayfs-common-files.patch
relayfs: common files
relayfs-remove-klog-debugging-channel.patch
relayfs - remove klog debugging channel
relayfs-locking-lockless-implementation.patch
relayfs: locking/lockless implementation
relayfs-headers.patch
relayfs: headers
relayfs-remove-klog-debugging-channel-headers.patch
relayfs - remove klog debugging channel
ltt-core-implementation.patch
ltt: core implementation
ltt-core-headers.patch
ltt: core headers
mips-fixed-ltt-build-errors.patch
mips: fixed LTT build errors
ltt-kconfig-fix.patch
ltt kconfig fix
ltt-doesnt-build-on-x86_64.patch
ltt doesn't build on x86_64
ltt-kernel-events.patch
ltt: kernel/ events
ltt-kernel-events-tidy.patch
ltt-kernel-events tidy
ltt-kernel-events-build-fix.patch
ltt-kernel-events-build-fix
ltt-fs-events.patch
ltt: fs/ events
ltt-fs-events-tidy.patch
ltt-fs-events tidy
ltt-ipc-events.patch
ltt: ipc/ events
ltt-mm-events.patch
ltt: mm/ events
ltt-net-events.patch
ltt: net/ events
ltt-architecture-events.patch
ltt: architecture events
pcmcia-tcic-eleminate-deprecated-check_region.patch
pcmcia: tcic: eleminate deprecated check_region()
pcmcia-i82365-use-config_pnp-instead-of-__isapnp__.patch
pcmcia: i82365: use CONFIG_PNP instead of __ISAPNP__
pcmcia-i82092-fix-checking-of-return-value-from-request_region.patch
pcmcia: i82092: fix checking of return value from request_region
pcmcia-socket-acregion-are-unused.patch
pcmcia: socket->{a,c}region are unused
pcmcia-use-unsigned-long-for-io-port-address.patch
pcmcia: use unsigned long for IO port address
nfs-fix_vfsflock.patch
VFS: Fix structure initialization in locks_remove_flock()
nfs-flock.patch
NFS: Add emulation of BSD flock() in terms of POSIX locks on the server
nfsacl-protocol-extension-for-nfsv3.patch
NFSACL protocol extension for NFSv3: generalise qsort()
nfsacl-return-enosys-for-rpc-programs-that-are-unavailable.patch
nfsacl: return -ENOSYS for RPC programs that are unavailable
nfsacl-add-missing-eopnotsupp-=-nfs3err_notsupp-mapping-in-nfsd.patch
nfsacl: add missing -EOPNOTSUPP => NFS3ERR_NOTSUPP mapping in nfsd
nfsacl-allow-multiple-programs-to-listen-on-the-same-port.patch
nfsacl: allow multiple programs to listen on the same port
nfsacl-allow-multiple-programs-to-share-the-same-transport.patch
nfsacl: allow multiple programs to share the same transport
nfsacl-lazy-rpc-receive-buffer-allocation.patch
nfsacl: lazy RPC receive buffer allocation
nfsacl-encode-and-decode-arbitrary-xdr-arrays.patch
nfsacl: encode and decode arbitrary XDR arrays
nfsacl-encode-and-decode-arbitrary-xdr-arrays-fix.patch
nfsacl-encode-and-decode-arbitrary-xdr-arrays-fix
nfsacl-add-noacl-nfs-mount-option.patch
nfsacl: add noacl nfs mount option
nfsacl-infrastructure-and-server-side-of-nfsacl.patch
nfsacl: infrastructure and server side of nfsacl
nfsacl-solaris-nfsacl-workaround.patch
nfsacl: solaris nfsacl workaround
nfsacl-client-side-of-nfsacl.patch
nfsacl: client side of nfsacl
nfsacl-acl-umask-handling-workaround-in-nfs-client.patch
nfsacl: aCL umask handling workaround in nfs client
nfsacl-cache-acls-on-the-nfs-client-side.patch
nfsacl: cache acls on the nfs client side
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdbL warning fix
kgdb buffer overflow fix
kgdbL warning fix
kgdb: CONFIG_DEBUG_INFO fix
x86_64 fixes
correct kgdb.txt Documentation link (against 2.6.1-rc1-mm2)
kgdb: fix for recent gcc
kgdb warning fixes
THREAD_SIZE fixes for kgdb
Fix stack overflow test for non-8k stacks
kgdb-ga.patch fix for i386 single-step into sysenter
fix TRAP_BAD_SYSCALL_EXITS on i386
add TRAP_BAD_SYSCALL_EXITS config for i386
kgdb-is-incompatible-with-kprobes
kgdb-ga-build-fix
kgdb-ga-fixes
kgdb-kill-off-highmem_start_page.patch
kgdb: kill off highmem_start_page
kgdboe-netpoll.patch
kgdb-over-ethernet via netpoll
kgdboe: fix configuration of MAC address
kgdb-x86_64-support.patch
kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
kgdb-x86_64-warning-fixes
kgdb-x86_64-fix
kgdb-x86_64-serial-fix
kprobes exception notifier fix
dev-mem-restriction-patch.patch
/dev/mem restriction patch
dev-mem-restriction-patch-allow-reads.patch
dev-mem-restriction-patch: allow reads
journal_add_journal_head-debug.patch
journal_add_journal_head-debug
list_del-debug.patch
list_del debug check
unplug-can-sleep.patch
unplug functions can sleep
firestream-warnings.patch
firestream warnings
perfctr-core.patch
perfctr: core
perfctr: remove bogus perfctr_sample_thread() calls
perfctr-i386.patch
perfctr: i386
perfctr-x86-core-updates.patch
perfctr x86 core updates
perfctr-x86-driver-updates.patch
perfctr x86 driver updates
perfctr-x86-driver-cleanup.patch
perfctr: x86 driver cleanup
perfctr-prescott-fix.patch
Prescott fix for perfctr
perfctr-x86-update-2.patch
perfctr x86 update 2
perfctr-x86_64.patch
perfctr: x86_64
perfctr-x86_64-core-updates.patch
perfctr x86_64 core updates
perfctr-ppc.patch
perfctr: PowerPC
perfctr-ppc32-driver-update.patch
perfctr: ppc32 driver update
perfctr-ppc32-mmcr0-handling-fixes.patch
perfctr ppc32 MMCR0 handling fixes
perfctr-ppc32-update.patch
perfctr ppc32 update
perfctr-ppc32-update-2.patch
perfctr ppc32 update
perfctr-virtualised-counters.patch
perfctr: virtualised counters
perfctr-remap_page_range-fix.patch
virtual-perfctr-illegal-sleep.patch
virtual perfctr illegal sleep
make-perfctr_virtual-default-in-kconfig-match-recommendation.patch
Make PERFCTR_VIRTUAL default in Kconfig match recommendation in help text
perfctr-ifdef-cleanup.patch
perfctr ifdef cleanup
perfctr-update-2-6-kconfig-related-updates.patch
perfctr: Kconfig-related updates
perfctr-virtual-updates.patch
perfctr virtual updates
perfctr-virtual-cleanup.patch
perfctr: virtual cleanup
perfctr-ppc32-preliminary-interrupt-support.patch
perfctr ppc32 preliminary interrupt support
perfctr-update-5-6-reduce-stack-usage.patch
perfctr: reduce stack usage
perfctr-interrupt-support-kconfig-fix.patch
perfctr interrupt_support Kconfig fix
perfctr-low-level-documentation.patch
perfctr low-level documentation
perfctr-inheritance-1-3-driver-updates.patch
perfctr inheritance: driver updates
perfctr-inheritance-2-3-kernel-updates.patch
perfctr inheritance: kernel updates
perfctr-inheritance-3-3-documentation-updates.patch
perfctr inheritance: documentation updates
perfctr-inheritance-locking-fix.patch
perfctr inheritance locking fix
perfctr-api-changes-first-step.patch
perfctr API changes: first step
perfctr-virtual-update.patch
perfctr virtual update
perfctr-x86-64-ia32-emulation-fix.patch
perfctr x86-64 ia32 emulation fix
perfctr-sysfs-update-1-4-core.patch
perfctr sysfs update: core
perfctr-sysfs-update.patch
Perfctr sysfs update
perfctr-sysfs-update-2-4-x86.patch
perfctr sysfs update: x86
perfctr-sysfs-update-3-4-x86-64.patch
perfctr sysfs update: x86-64
perfctr: syscall numbers in x86-64 ia32-emulation
perfctr x86_64 native syscall numbers fix
perfctr-sysfs-update-4-4-ppc32.patch
perfctr sysfs update: ppc32
sched-fix-preemption-race-core-i386.patch
sched: fix preemption race (Core/i386)
sched-make-use-of-preempt_schedule_irq-ppc.patch
sched: make use of preempt_schedule_irq() (PPC)
sched-make-use-of-preempt_schedule_irq-arm.patch
sched: make use of preempt_schedule_irq (ARM)
sched-isochronous-class-for-unprivileged-soft-rt-scheduling.patch
sched: Isochronous class for unprivileged soft rt scheduling
sched-account-rt_tasks-as-iso_ticks.patch
sched: account rt_tasks as iso_ticks
add-do_proc_doulonglongvec_minmax-to-sysctl-functions.patch
Add do_proc_doulonglongvec_minmax to sysctl functions
add-do_proc_doulonglongvec_minmax-to-sysctl-functions-fix
add-do_proc_doulonglongvec_minmax-to-sysctl-functions fix 2
add-sysctl-interface-to-sched_domain-parameters.patch
Add sysctl interface to sched_domain parameters
videotext-ioctls-changed-to-use-_io-macros.patch
videotext: ioctls changed to use _IO macros
video-arv-remove-casts.patch
video/arv: remove casts
video-w9966-remove-casts.patch
video/w9966: remove casts
video-zr36120-remove-casts.patch
video/zr36120: remove casts
v4l-video-buf-update.patch
v4l: video-buf update
v4l2-tuner-api-update.patch
v4l2 tuner api update
v4l-tuner-update.patch
v4l: tuner update
v4l-add-tveeprom-module.patch
v4l: add tveeprom module.
v4l-tvaudio-update.patch
v4l: tvaudio update
v4l-bttv-ir-input-driver-update.patch
v4l: bttv IR input driver update
v4l-bttv-update.patch
v4l: bttv update
v4l-saa7134-module.patch
v4l: saa7134 module
allow-modular-ide-pnp.patch
allow modular ide-pnp
allow-x86_64-to-reenable-interrupts-on-contention.patch
Allow x86_64 to reenable interrupts on contention
i386-cpu-hotplug-updated-for-mm.patch
i386 CPU hotplug updated for -mm
ppc64-fix-cpu-hotplug.patch
ppc64: fix hotplug cpu
serialize-access-to-ide-devices.patch
serialize access to ide devices
disable-atykb-warning.patch
disable atykb "too many keys pressed" warning
export-file_ra_state_init-again.patch
Export file_ra_state_init() again
cachefs-filesystem.patch
CacheFS filesystem
numa-policies-for-file-mappings-mpol_mf_move-cachefs.patch
numa-policies-for-file-mappings-mpol_mf_move for cachefs
cachefs-release-search-records-lest-they-return-to-haunt-us.patch
CacheFS: release search records lest they return to haunt us
fix-64-bit-problems-in-cachefs.patch
Fix 64-bit problems in cachefs
cachefs-fixed-typos-that-cause-wrong-pointer-to-be-kunmapped.patch
cachefs: fixed typos that cause wrong pointer to be kunmapped
cachefs-return-the-right-error-upon-invalid-mount.patch
CacheFS: return the right error upon invalid mount
fix-cachefs-barrier-handling-and-other-kernel-discrepancies.patch
Fix CacheFS barrier handling and other kernel discrepancies
remove-error-from-linux-cachefsh.patch
Remove #error from linux/cachefs.h
cachefs-warning-fix-2.patch
cachefs warning fix 2
cachefs-linkage-fix-2.patch
cachefs linkage fix
cachefs-build-fix.patch
cachefs build fix
cachefs-documentation.patch
CacheFS documentation
add-page-becoming-writable-notification.patch
Add page becoming writable notification
add-page-becoming-writable-notification-fix.patch
do_wp_page_mk_pte_writable() fix
add-page-becoming-writable-notification-build-fix.patch
add-page-becoming-writable-notification build fix
provide-a-filesystem-specific-syncable-page-bit.patch
Provide a filesystem-specific sync'able page bit
provide-a-filesystem-specific-syncable-page-bit-fix.patch
provide-a-filesystem-specific-syncable-page-bit-fix
provide-a-filesystem-specific-syncable-page-bit-fix-2.patch
provide-a-filesystem-specific-syncable-page-bit-fix-2
make-afs-use-cachefs.patch
Make AFS use CacheFS
afs-cachefs-dependency-fix.patch
afs-cachefs-dependency-fix
split-general-cache-manager-from-cachefs.patch
Split general cache manager from CacheFS
turn-cachefs-into-a-cache-backend.patch
Turn CacheFS into a cache backend
rework-the-cachefs-documentation-to-reflect-fs-cache-split.patch
Rework the CacheFS documentation to reflect FS-Cache split
update-afs-client-to-reflect-cachefs-split.patch
Update AFS client to reflect CacheFS split
x86-rename-apic_mode_exint.patch
kexec: x86: rename APIC_MODE_EXINT
x86-local-apic-fix.patch
kexec: x86: local apic fix
x86_64-e820-64bit.patch
kexec: x86_64: e820 64bit fix
x86-i8259-shutdown.patch
kexec: x86: i8259 shutdown: disable interrupts
x86_64-i8259-shutdown.patch
kexec: x86_64: add i8259 shutdown method
x86-apic-virtwire-on-shutdown.patch
kexec: x86: resture apic virtual wire mode on shutdown
x86_64-apic-virtwire-on-shutdown.patch
kexec: x86_64: restore apic virtual wire mode on shutdown
vmlinux-fix-physical-addrs.patch
kexec: vmlinux: fix physical addresses
x86-vmlinux-fix-physical-addrs.patch
kexec: x86: vmlinux: fix physical addresses
x86_64-vmlinux-fix-physical-addrs.patch
kexec: x86_64: vmlinux: fix physical addresses
x86_64-entry64.patch
kexec: x86_64: add 64-bit entry
x86-config-kernel-start.patch
kexec: x86: add CONFIG_PYSICAL_START
x86_64-config-kernel-start.patch
kexec: x86_64: add CONFIG_PHYSICAL_START
kexec-kexec-generic.patch
kexec: add kexec syscalls
x86-machine_shutdown.patch
kexec: x86: factor out apic shutdown code
x86-kexec.patch
kexec: x86 kexec core
x86-crashkernel.patch
crashdump: x86 crashkernel option
x86_64-machine_shutdown.patch
kexec: x86_64: factor out apic shutdown code
x86_64-kexec.patch
kexec: x86_64 kexec implementation
x86_64-crashkernel.patch
crashdump: x86_64: crashkernel option
kexec-ppc-support.patch
kexec: kexec ppc support
x86-crash_shutdown-nmi-shootdown.patch
crashdump: x86: add NMI handler to capture other CPUs
x86-crash_shutdown-snapshot-registers.patch
kexec: x86: snapshot registers during crash shutdown
x86-crash_shutdown-apic-shutdown.patch
kexec: x86 shutdown APICs during crash_shutdown
crashdump-documentation.patch
crashdump: documentation
crashdump-memory-preserving-reboot-using-kexec.patch
crashdump: memory preserving reboot using kexec
crashdump-routines-for-copying-dump-pages.patch
crashdump: routines for copying dump pages
crashdump-elf-format-dump-file-access.patch
crashdump: elf format dump file access
crashdump-linear-raw-format-dump-file-access.patch
crashdump: linear raw format dump file access
crashdump-reserving-backup-region-for-kexec-based.patch
crashdump: reserving backup region for kexec based crashdumps.
new-bitmap-list-format-for-cpusets.patch
new bitmap list format (for cpusets)
cpusets-big-numa-cpu-and-memory-placement.patch
cpusets - big numa cpu and memory placement
cpusets-config_cpusets-depends-on-smp.patch
Cpusets: CONFIG_CPUSETS depends on SMP
cpusets-move-cpusets-above-embedded.patch
move CPUSETS above EMBEDDED
cpusets-fix-cpuset_get_dentry.patch
cpusets : fix cpuset_get_dentry()
cpusets-fix-race-in-cpuset_add_file.patch
cpusets: fix race in cpuset_add_file()
cpusets-remove-more-casts.patch
cpusets: remove more casts
cpusets-make-config_cpusets-the-default-in-sn2_defconfig.patch
cpusets: make CONFIG_CPUSETS the default in sn2_defconfig
cpusets-document-proc-status-allowed-fields.patch
cpusets: document proc status allowed fields
cpusets-dont-export-proc_cpuset_operations.patch
Cpusets - Dont export proc_cpuset_operations
cpusets-display-allowed-masks-in-proc-status.patch
cpusets: display allowed masks in proc status
cpusets-simplify-cpus_allowed-setting-in-attach.patch
cpusets: simplify cpus_allowed setting in attach
cpusets-remove-useless-validation-check.patch
cpusets: remove useless validation check
cpusets-tasks-file-simplify-format-fixes.patch
Cpusets tasks file: simplify format, fixes
cpusets-simplify-memory-generation.patch
Cpusets: simplify memory generation
cpusets-interoperate-with-hotplug-online-maps.patch
cpusets: interoperate with hotplug online maps
cpusets-alternative-fix-for-possible-race-in.patch
cpusets: alternative fix for possible race in cpuset_tasks_read()
cpusets-remove-casts.patch
cpusets: remove void* typecasts
reiser4-sb_sync_inodes.patch
reiser4: vfs: add super_operations.sync_inodes()
reiser4-allow-drop_inode-implementation.patch
reiser4: export vfs inode.c symbols
reiser4-truncate_inode_pages_range.patch
reiser4: vfs: add truncate_inode_pages_range()
reiser4-export-remove_from_page_cache.patch
reiser4: export pagecache add/remove functions to modules
reiser4-export-page_cache_readahead.patch
reiser4: export page_cache_readahead to modules
reiser4-reget-page-mapping.patch
reiser4: vfs: re-check page->mapping after calling try_to_release_page()
reiser4-rcu-barrier.patch
reiser4: add rcu_barrier() synchronization point
reiser4-export-inode_lock.patch
reiser4: export inode_lock to modules
reiser4-export-pagevec-funcs.patch
reiser4: export pagevec functions to modules
reiser4-export-radix_tree_preload.patch
reiser4: export radix_tree_preload() to modules
reiser4-export-find_get_pages.patch
reiser4-radix-tree-tag.patch
reiser4: add new radix tree tag
reiser4-radix_tree_lookup_slot.patch
reiser4: add radix_tree_lookup_slot()
reiser4-perthread-pages.patch
reiser4: per-thread page pools
reiser4-include-reiser4.patch
reiser4: add to build system
reiser4-doc.patch
reiser4: documentation
reiser4-only.patch
reiser4: main fs
reiser4-recover-read-performance.patch
reiser4: recover read performance
reiser4-export-find_get_pages_tag.patch
reiser4-export-find_get_pages_tag
reiser4-add-missing-context.patch
add-acpi-based-floppy-controller-enumeration.patch
Add ACPI-based floppy controller enumeration.
possible-dcache-bug-debugging-patch.patch
Possible dcache BUG: debugging patch
serial-add-support-for-non-standard-xtals-to-16c950-driver.patch
serial: add support for non-standard XTALs to 16c950 driver
add-support-for-possio-gcc-aka-pcmcia-siemens-mc45.patch
Add support for Possio GCC AKA PCMCIA Siemens MC45
generic-serial-cli-conversion.patch
generic-serial cli() conversion
specialix-io8-cli-conversion.patch
Specialix/IO8 cli() conversion
sx-cli-conversion.patch
SX cli() conversion
revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.patch
revert "allow OEM written modules to make calls to ia64 OEM SAL functions"
md-add-interface-for-userspace-monitoring-of-events.patch
md: add interface for userspace monitoring of events.
make-acpi_bus_register_driver-consistent-with-pci_register_driver-again.patch
make acpi_bus_register_driver() consistent with pci_register_driver()
remove-lock_section-from-x86_64-spin_lock-asm.patch
remove LOCK_SECTION from x86_64 spin_lock asm
kfree_skb-dump_stack.patch
kfree_skb-dump_stack
cancel_rearming_delayed_work.patch
cancel_rearming_delayed_work()
make cancel_rearming_delayed_workqueue static
ipvs-deadlock-fix.patch
ipvs deadlock fix
minimal-ide-disk-updates.patch
Minimal ide-disk updates
use-find_trylock_page-in-free_swap_and_cache-instead-of-hand-coding.patch
use find_trylock_page in free_swap_and_cache instead of hand coding
radeonfb-set-accelerator-id.patch
radeonfb: Set accelerator id
vesafb-change-return-error-id.patch
vesafb: Change return error id
intelfb-workaround-for-830m.patch
intelfb: Workaround for 830M
fbcon-save-blank-state-last.patch
fbcon: Save blank state last
backlight-fix-compile-error-if-config_fb-is-unset.patch
backlight: Fix compile error if CONFIG_FB is unset
matroxfb-fb_matrox_g-kconfig-changes.patch
matroxfb: FB_MATROX_G Kconfig changes
raid5-overlapping-read-hack.patch
raid5 overlapping read hack
include-type-information-as-module-info-where-possible.patch
Include type information as module info where possible
figure-out-who-is-inserting-bogus-modules.patch
Figure out who is inserting bogus modules
detect-atomic-counter-underflows.patch
detect atomic counter underflows
post-halloween-doc.patch
post halloween doc
fix-architecture-names-in-hugetlbpagetxt.patch
fix architecture names in hugetlbpage.txt
periodically-scan-redzone-entries-and-slab-control-structures.patch
periodically scan redzone entries and slab control structures
fuse-maintainers-kconfig-and-makefile-changes.patch
Subject: [PATCH 1/11] FUSE - MAINTAINERS, Kconfig and Makefile changes
fuse-core.patch
Subject: [PATCH 2/11] FUSE - core
fuse-device-functions.patch
Subject: [PATCH 3/11] FUSE - device functions
fuse-fix-llseek-on-device.patch
FUSE: fix llseek on device
fuse-make-two-functions-static.patch
fuse: make two functions static
fuse-fix-variable-with-confusing-name.patch
fuse: fix variable with confusing name
fuse-read-only-operations.patch
Subject: [PATCH 4/11] FUSE - read-only operations
fuse-read-write-operations.patch
Subject: [PATCH 5/11] FUSE - read-write operations
fuse-file-operations.patch
Subject: [PATCH 6/11] FUSE - file operations
fuse-mount-options.patch
Subject: [PATCH 7/11] FUSE - mount options
fuse-dont-check-against-zero-fsuid.patch
fuse: don't check against zero fsuid
fuse-remove-mount_max-and-user_allow_other-module-parameters.patch
fuse: remove mount_max and user_allow_other module parameters
fuse-extended-attribute-operations.patch
Subject: [PATCH 8/11] FUSE - extended attribute operations
fuse-readpages-operation.patch
Subject: [PATCH 9/11] FUSE - readpages operation
fuse-nfs-export.patch
Subject: [PATCH 10/11] FUSE - NFS export
fuse-direct-i-o.patch
Subject: [PATCH 11/11] FUSE - direct I/O
fuse-transfer-readdir-data-through-device.patch
fuse: transfer readdir data through device
ieee1394-adds-a-disable_irm-option-to-ieee1394ko.patch
ieee1394: add a disable_irm option to ieee1394.ko
cryptoapi-prepare-for-processing-multiple-buffers-at.patch
CryptoAPI: prepare for processing multiple buffers at a time
cryptoapi-update-padlock-to-process-multiple-blocks-at.patch
CryptoAPI: Update PadLock to process multiple blocks at once
update-email-address-of-andrea-arcangeli.patch
update email address of Andrea Arcangeli
compile-error-blackbird_load_firmware.patch
blackbird_load_firmware compile fix
i386-x86_64-apicc-make-two-functions-static.patch
i386/x86_64 apic.c: make two functions static
i386-cyrixc-make-a-function-static.patch
i386 cyrix.c: make a function static
mtrr-some-cleanups.patch
mtrr: some cleanups
i386-cpu-commonc-some-cleanups.patch
i386 cpu/common.c: some cleanups
i386-cpuidc-make-two-functions-static.patch
i386 cpuid.c: make two functions static
i386-efic-make-some-code-static.patch
i386 efi.c: make some code static
i386-x86_64-io_apicc-misc-cleanups.patch
i386/x86_64 io_apic.c: misc cleanups
i386-mpparsec-make-mp_processor_info-static.patch
i386 mpparse.c: make MP_processor_info static
i386-x86_64-msrc-make-two-functions-static.patch
i386/x86_64 msr.c: make two functions static
3w-abcdh-tw_device_extension-remove-an-unused-filed.patch
3w-abcd.h: TW_Device_Extension: remove an unused field
hpet-make-some-code-static.patch
hpet: make some code static
26-patch-i386-trapsc-make-a-function-static.patch
i386 traps.c: make a function static
i386-semaphorec-make-4-functions-static.patch
i386 semaphore.c: make 4 functions static
i386-rebootc-cleanups.patch
i386: reboot.c cleanups
kill-aux_device_present.patch
kill aux_device_present
i386-setupc-make-4-variables-static.patch
i386 setup.c: make 4 variables static
mostly-i386-mm-cleanup.patch
(mostly i386) mm cleanup
scsi-megaraid_mmc-make-some-code-static.patch
SCSI megaraid_mm.c: make some code static
update-email-address-of-benjamin-lahaise.patch
Update email address of Benjamin LaHaise
add-map_populate-sys_remap_file_pages-support-to-xfs.patch
add MAP_POPULATE/sys_remap_file_pages support to XFS
update-email-address-of-philip-blundell.patch
Update email address of Philip Blundell
mm-filemapc-make-a-function-static.patch
mm/filemap.c: make a function static
kernel-acctc-make-a-function-static.patch
kernel/acct.c: make a function static
kernel-auditc-make-some-functions-static.patch
kernel/audit.c: make some functions static
kernel-capabilityc-make-a-spinlock-static.patch
kernel/capability.c: make a spinlock static
mm-thrashc-make-a-variable-static.patch
mm/thrash.c: make a variable static
lib-kernel_lockc-make-kernel_sem-static.patch
lib/kernel_lock.c: make kernel_sem static
saa7146_vv_ksymsc-remove-two-unused-export_symbol_gpls.patch
saa7146_vv_ksyms.c: remove two unused EXPORT_SYMBOL_GPL's
fix-placement-of-static-inline-in-nfsdh.patch
fix placement of static inline in nfsd.h
drivers-block-umemc-make-two-functions-static.patch
drivers/block/umem.c: make two functions static
drivers-block-xdc-make-a-variable-static.patch
drivers/block/xd.c: make a variable static
kernel-configsc-make-a-variable-static.patch
kernel/configs.c: make a variable static
kernel-forkc-make-mm_cachep-static.patch
kernel/fork.c: make mm_cachep static
kernel-kallsymsc-make-some-code-static.patch
kernel/kallsyms.c: make some code static
mm-page-writebackc-remove-an-unused-function.patch
mm/page-writeback.c: remove an unused function
mm-shmemc-make-a-struct-static.patch
mm/shmem.c: make a struct static
misc-isapnp-cleanups.patch
misc ISAPNP cleanups
some-pnp-cleanups.patch
some PNP cleanups
if-0-cx88_risc_disasm.patch
#if 0 cx88_risc_disasm
make-loglevels-in-init-mainc-a-little-more-sane.patch
Make loglevels in init/main.c a little more sane.
isicom-use-null-for-pointer.patch
sparse: use NULL for pointer
remove-bouncing-email-address-of-hennus-bergman.patch
remove bouncing email address of Hennus Bergman
cirrusfbc-make-some-code-static.patch
cirrusfb.c: make some code static
matroxfb_basec-make-some-code-static.patch
matroxfb_base.c: make some code static
asiliantfbc-make-some-code-static.patch
asiliantfb.c: make some code static
i386-apic-kconfig-cleanups.patch
i386 APIC Kconfig cleanups
security-seclvlc-make-some-code-static.patch
security/seclvl.c: make some code static
drivers-block-elevatorc-make-two-functions-static.patch
drivers/block/elevator.c: make two functions static
drivers-block-rdc-make-two-variables-static.patch
drivers/block/rd.c: make two variables static
loopc-make-two-functions-static.patch
loop.c: make two functions static
remove-bouncing-email-address-of-thomas-hood.patch
remove bouncing email address of Thomas Hood
fs-adfs-dir_fc-remove-an-unused-function.patch
fs/adfs/dir_f.c: remove an unused function
drivers-char-moxac-if-0-an-unused-function.patch
drivers/char/moxa.c: #if 0 an unused function
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>...
Before people start complaining it wouldn't apply:
s/rc1/rc2/g
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc1-mm2:
>...
> +v4l-saa7134-module.patch
>
> v4l updates.
>...
This patch broke compilation with CONFIG_MODULES=n:
<-- snip -->
...
CC drivers/media/video/saa7134/saa7134-core.o
drivers/media/video/saa7134/saa7134-core.c: In function `pending_call':
drivers/media/video/saa7134/saa7134-core.c:234: error: `MODULE_STATE_LIVE' undeclared (first use in this function)
drivers/media/video/saa7134/saa7134-core.c:234: error: (Each undeclared identifier is reported only once
drivers/media/video/saa7134/saa7134-core.c:234: error: for each function it appears in.)
drivers/media/video/saa7134/saa7134-core.c: In function `request_module_depend':
drivers/media/video/saa7134/saa7134-core.c:251: error: dereferencing pointer to incomplete type
drivers/media/video/saa7134/saa7134-core.c:252: error: `MODULE_STATE_COMING' undeclared (first use in this function)
drivers/media/video/saa7134/saa7134-core.c:259: error: `MODULE_STATE_LIVE' undeclared (first use in this function)
make[4]: *** [drivers/media/video/saa7134/saa7134-core.o] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Andrew Morton a ?crit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>
>
> - Lots of updates and fixes all over the place.
Hi Andrew,
X does not work anymore when using DRI on my Compaq Evo N600c (Radeon Mobility M6 LY).
My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel modules.
Instead of the usual gdm window, I get a black or noisy screen (remaining image parts of
last working session). The mouse pointer works. Sysrq works. But Caps-lock doesn't work.
The machine pings but I can't ssh.
I don't know exactly what's happening. I don't see anything interesting in dmesg.
Removing DRI from Xfree config (even if drm/radeon modules are loaded) makes X work again.
Linus' 2.6.11-rc2 works fine.
.config and lspci attached.
Regards,
Brice
> +i4l-new-hfc_usb-driver-version.patch
this drivers wants:
- update for Documentation/CodingStyle
- conversion to proper pci API
> +posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
umm, this adds extreme obsfucation. Roland, please try to follow normal
Linux style, thanks.
> inotify.patch
> inotify
Haven't had time to look at the current implementation, but the in-kernel
interface is still horrible as it duplicates the dnotify calls all over the
place, using IN_FOO instead of DN_FOO. Please add a layer of notify_foo
wrappers that calls into both.
Also ioctl is not an acceptable interface for adding new core functionality.
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc1-mm2:
>...
> bk-i2c.patch
>...
> Latest versions of various bk trees
>...
This causes the following compile error:
<-- snip -->
...
LD drivers/superio/built-in.o
drivers/superio/sc_acb.o(.text+0x0): In function `sc_write_reg':
: multiple definition of `sc_write_reg'
drivers/superio/sc_gpio.o(.text+0x0): first defined here
drivers/superio/sc_acb.o(.text+0x30): In function `sc_read_reg':
: multiple definition of `sc_read_reg'
drivers/superio/sc_gpio.o(.text+0x30): first defined here
make[2]: *** [drivers/superio/built-in.o] Error 1
<-- snip -->
The trivial fix for these needlessly global functions is below.
BTW1: pin_test.c is added but completely unused.
BTW2: bk-i2c adds a whole bunch of unused SuperIO EXPORT_SYMBOL's.
Is usage for them expected very soon or shall I send a patch to
remove them?
<-- snip -->
This patch makes needlessly global functions static fixing a compile
error if both sc_acb.c and sc_gpio.c are compiled statically into the
kernel.
Signed-off-by: Adrian Bunk <[email protected]>
---
drivers/superio/sc_acb.c | 4 ++--
drivers/superio/sc_gpio.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.11-rc2-mm1-full/drivers/superio/sc_acb.c.old 2005-01-24 12:28:22.000000000 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/superio/sc_acb.c 2005-01-24 12:29:23.000000000 +0100
@@ -48,13 +48,13 @@
.orig_ldev = NULL,
};
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
+static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
{
outb(reg, dev->base_index);
outb(val, dev->base_data);
}
-u8 sc_read_reg(struct sc_dev *dev, u8 reg)
+static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
{
u8 val;
--- linux-2.6.11-rc2-mm1-full/drivers/superio/sc_gpio.c.old 2005-01-24 12:29:48.000000000 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/superio/sc_gpio.c 2005-01-24 12:29:58.000000000 +0100
@@ -50,13 +50,13 @@
static void sc_gpio_write_event(void *data, int pin_number, u8 byte);
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
+static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
{
outb(reg, dev->base_index);
outb(val, dev->base_data);
}
-u8 sc_read_reg(struct sc_dev *dev, u8 reg)
+static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
{
u8 val;
On Mon, Jan 24, 2005 at 01:25:41PM +0100, Adrian Bunk wrote:
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.11-rc1-mm2:
> >...
> > bk-i2c.patch
> >...
> > Latest versions of various bk trees
> >...
>
> This causes the following compile error:
Where's that code coming from anyone? Greg seems to be adding tons of not fully
reviewed stuff lately..
The following compile error comes from Linus' tree:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o(.bss+0xd50e4): multiple definition of `debug'
arch/i386/kernel/built-in.o(.text+0x2e4c): first defined here
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
The offender is in drivers/media/dvb/dibusb/dvb-dibusb-core.c:
"debug" is not a good name for a global variable...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, 2005-01-24 at 12:34 +0000, Christoph Hellwig wrote:
> On Mon, Jan 24, 2005 at 01:25:41PM +0100, Adrian Bunk wrote:
> > On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.11-rc1-mm2:
> > >...
> > > bk-i2c.patch
> > >...
> > > Latest versions of various bk trees
> > >...
> >
> > This causes the following compile error:
>
> Where's that code coming from anyone? Greg seems to be adding tons of not fully
> reviewed stuff lately..
That code was written by me.
Please provide full error output, since it is compiled successfully
here.
Thank you.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
Brice Goglin a ?crit :
> Andrew Morton a ?crit :
>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>>
>>
>>
>> - Lots of updates and fixes all over the place.
>
>
> Hi Andrew,
>
> X does not work anymore when using DRI on my Compaq Evo N600c (Radeon
> Mobility M6 LY).
> My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel
> modules.
>
> Instead of the usual gdm window, I get a black or noisy screen
> (remaining image parts of
> last working session). The mouse pointer works. Sysrq works. But
> Caps-lock doesn't work.
> The machine pings but I can't ssh.
>
> I don't know exactly what's happening. I don't see anything interesting
> in dmesg.
Thanks to Benoit who found this at the end of dmesg:
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Couldn't find an AGP VGA controller.
while Linus' 2.6.11-rc2 says:
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
Regards,
Brice
Hi,
On Mon, 24 Jan 2005, Andrew Morton wrote:
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
>
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
I introduced a stupid typo. The patch below should fix.
After completing rechecking and testing the patch I'll send you a rediffed
version.
bye, Roman
diff -ur -X /home/devel/roman/nodiff linux-2.6.11-rc2-mm1.org/drivers/char/vt.c linux-2.6.11-rc2-mm1/drivers/char/vt.c
--- linux-2.6.11-rc2-mm1.org/drivers/char/vt.c 2005-01-24 14:16:18.000000000 +0100
+++ linux-2.6.11-rc2-mm1/drivers/char/vt.c 2005-01-24 14:18:25.000000000 +0100
@@ -212,6 +212,8 @@
* Low-Level Functions
*/
+#define IS_FG(vc) ((vc)->vc_num == fg_console)
+
#ifdef VT_BUF_VRAM_ONLY
#define DO_UPDATE(vc) 0
#else
@@ -544,7 +546,7 @@
static void set_cursor(struct vc_data *vc)
{
- if (!vc->vc_num != fg_console || console_blanked ||
+ if (!IS_FG(vc) || console_blanked ||
vc->vc_mode == KD_GRAPHICS)
return;
if (vc->vc_deccm) {
@@ -1953,7 +1955,7 @@
charmask = himask ? 0x1ff : 0xff;
/* undraw cursor first */
- if (currcons == fg_console)
+ if (IS_FG(vc))
hide_cursor(vc);
while (!tty->stopped && count) {
@@ -2166,7 +2168,7 @@
goto quit;
/* undraw cursor first */
- if (vc->vc_num == fg_console)
+ if (IS_FG(vc))
hide_cursor(vc);
start = (ushort *)vc->vc_pos;
On Mon, 2005-01-24 at 16:04 +0300, Evgeniy Polyakov wrote:
> On Mon, 2005-01-24 at 12:34 +0000, Christoph Hellwig wrote:
> > On Mon, Jan 24, 2005 at 01:25:41PM +0100, Adrian Bunk wrote:
> > > On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > > >...
> > > > Changes since 2.6.11-rc1-mm2:
> > > >...
> > > > bk-i2c.patch
> > > >...
> > > > Latest versions of various bk trees
> > > >...
> > >
> > > This causes the following compile error:
> >
> > Where's that code coming from anyone? Greg seems to be adding tons of not fully
> > reviewed stuff lately..
>
> That code was written by me.
> Please provide full error output, since it is compiled successfully
> here.
>
> Thank you.
Ok, I found following in the archive:
******************************************
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc1-mm2:
>...
> bk-i2c.patch
>...
> Latest versions of various bk trees
>...
This causes the following compile error:
<-- snip -->
...
LD drivers/superio/built-in.o
drivers/superio/sc_acb.o(.text+0x0): In function `sc_write_reg':
: multiple definition of `sc_write_reg'
drivers/superio/sc_gpio.o(.text+0x0): first defined here
drivers/superio/sc_acb.o(.text+0x30): In function `sc_read_reg':
: multiple definition of `sc_read_reg'
drivers/superio/sc_gpio.o(.text+0x30): first defined here
make[2]: *** [drivers/superio/built-in.o] Error 1
<-- snip -->
The trivial fix for these needlessly global functions is below.
BTW1: pin_test.c is added but completely unused.
BTW2: bk-i2c adds a whole bunch of unused SuperIO EXPORT_SYMBOL's.
Is usage for them expected very soon or shall I send a patch to
remove them?
<-- snip -->
This patch makes needlessly global functions static fixing a compile
error if both sc_acb.c and sc_gpio.c are compiled statically into the
kernel.
*********************************
It is not Greg, but completely my fault and I agree with your changes.
pin_test.c was added as example of how to use SuperIO subsystem,
it is not supposed to be compiled, it is an example, probably it should
live in Documentation/superio/example.c
Tahnk you for review.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Mon, Jan 24, 2005 at 12:17:13PM +0100, Adrian Bunk wrote:
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> >...
> > +v4l-saa7134-module.patch
>
> This patch broke compilation with CONFIG_MODULES=n:
>
> drivers/media/video/saa7134/saa7134-core.c: In function `pending_call':
> drivers/media/video/saa7134/saa7134-core.c:234: error: `MODULE_STATE_LIVE' undeclared (first use in this function)
The patch below should fix this.
Gerd
Index: linux-2.6.11-rc2/drivers/media/video/saa7134/saa7134-core.c
===================================================================
--- linux-2.6.11-rc2.orig/drivers/media/video/saa7134/saa7134-core.c 2005-01-24 11:05:45.000000000 +0100
+++ linux-2.6.11-rc2/drivers/media/video/saa7134/saa7134-core.c 2005-01-24 14:54:29.000000000 +0100
@@ -21,6 +21,7 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include <linux/config.h>
#include <linux/init.h>
#include <linux/list.h>
#include <linux/module.h>
@@ -225,6 +226,8 @@ static void dump_statusregs(struct saa71
/* ----------------------------------------------------------- */
/* delayed request_module */
+#ifdef CONFIG_MODULES
+
static int need_empress;
static int need_dvb;
@@ -265,6 +268,12 @@ static void request_module_depend(char *
}
}
+#else
+
+static inline void request_module_depend(char *name, int *flag) {}
+
+#endif /* CONFIG_MODULES */
+
/* ------------------------------------------------------------------ */
/* nr of (saa7134-)pages for the given buffer size */
Remove unneded exports and make some functions static.
Signed-off-by: Evgeniy Polyakov <[email protected]>
diff -ru linux-2.6/drivers/superio.orig/sc_acb.c
linux-2.6/drivers/superio/sc_acb.c
--- linux-2.6/drivers/superio.orig/sc_acb.c 2005-01-24
17:07:28.295779728 +0300
+++ linux-2.6/drivers/superio/sc_acb.c 2005-01-24 17:09:35.377460376
+0300
@@ -29,10 +29,10 @@
#include "sc.h"
#include "sc_acb.h"
-int sc_acb_activate(void *data);
-u8 sc_acb_read(void *data, int reg);
-void sc_acb_write(void *data, int reg, u8 byte);
-void sc_acb_control(void *data, int pin, u8 mask, u8 ctl);
+static int sc_acb_activate(void *data);
+static u8 sc_acb_read(void *data, int reg);
+static void sc_acb_write(void *data, int reg, u8 byte);
+static void sc_acb_control(void *data, int pin, u8 mask, u8 ctl);
static struct logical_dev ldev_acb = {
.name = "ACB",
@@ -48,13 +48,13 @@
.orig_ldev = NULL,
};
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
+static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
{
outb(reg, dev->base_index);
outb(val, dev->base_data);
}
-u8 sc_read_reg(struct sc_dev *dev, u8 reg)
+static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
{
u8 val;
@@ -64,7 +64,7 @@
return val;
}
-int sc_acb_activate(void *data)
+static int sc_acb_activate(void *data)
{
struct logical_dev *ldev = (struct logical_dev *)data;
u8 val;
@@ -111,7 +111,7 @@
return 0;
}
-u8 sc_acb_read(void *data, int reg)
+static u8 sc_acb_read(void *data, int reg)
{
struct logical_dev *ldev = (struct logical_dev *)data;
u8 val;
@@ -123,7 +123,7 @@
return val;
}
-void sc_acb_write(void *data, int reg, u8 byte)
+static void sc_acb_write(void *data, int reg, u8 byte)
{
struct logical_dev *ldev = (struct logical_dev *)data;
@@ -132,7 +132,7 @@
outb(byte, ldev->base_addr + reg);
}
-void sc_acb_control(void *data, int pin, u8 mask, u8 ctl)
+static void sc_acb_control(void *data, int pin, u8 mask, u8 ctl)
{
}
@@ -156,8 +156,3 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Evgeniy Polyakov <[email protected]>");
MODULE_DESCRIPTION("Driver for Access Bus logical device.");
-
-EXPORT_SYMBOL(sc_acb_activate);
-EXPORT_SYMBOL(sc_acb_read);
-EXPORT_SYMBOL(sc_acb_write);
-EXPORT_SYMBOL(sc_acb_control);
diff -ru linux-2.6/drivers/superio.orig/sc_gpio.c
linux-2.6/drivers/superio/sc_gpio.c
--- linux-2.6/drivers/superio.orig/sc_gpio.c 2005-01-24
17:07:28.305778208 +0300
+++ linux-2.6/drivers/superio/sc_gpio.c 2005-01-24 17:10:44.808905192
+0300
@@ -31,6 +31,14 @@
static struct gpio_pin gpin[SIO_GPIO_NPINS];
+static int sc_gpio_activate(void *);
+static u8 sc_gpio_read(void *, int);
+static void sc_gpio_write(void *, int, u8);
+static void sc_gpio_control(void *, int, u8, u8);
+static void sc_gpio_pin_select(void *, int);
+static irqreturn_t sc_gpio_interrupt(int, void *, struct pt_regs *);
+
+
static struct logical_dev ldev_gpio = {
.name = "GPIO",
.index = SIO_LDN_GPIO,
@@ -50,13 +58,13 @@
static void sc_gpio_write_event(void *data, int pin_number, u8 byte);
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
+static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
{
outb(reg, dev->base_index);
outb(val, dev->base_data);
}
-u8 sc_read_reg(struct sc_dev *dev, u8 reg)
+static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
{
u8 val;
@@ -66,7 +74,7 @@
return val;
}
-irqreturn_t sc_gpio_interrupt(int irq, void *data, struct pt_regs *
regs)
+static irqreturn_t sc_gpio_interrupt(int irq, void *data, struct
pt_regs * regs)
{
struct logical_dev *ldev = (struct logical_dev *)data;
static u8 r[4], e[2], s[2];
@@ -122,7 +130,7 @@
}
-void sc_gpio_pin_select(void *data, int pin_number)
+static void sc_gpio_pin_select(void *data, int pin_number)
{
struct logical_dev *ldev = (struct logical_dev *)data;
int port, pin;
@@ -136,7 +144,7 @@
sc_write_reg(ldev->pdev, SIO_GPIO_PINSEL, val);
}
-int sc_gpio_activate(void *data)
+static int sc_gpio_activate(void *data)
{
struct logical_dev *ldev = (struct logical_dev *)data;
int i;
@@ -161,7 +169,7 @@
return 0;
}
-u8 sc_gpio_read(void *data, int pin_number)
+static u8 sc_gpio_read(void *data, int pin_number)
{
struct logical_dev *ldev = (struct logical_dev *)data;
int port, pin;
@@ -222,7 +230,7 @@
outb(1<<pin, ldev->base_addr + reg+1);
}
-void sc_gpio_write(void *data, int pin_number, u8 byte)
+static void sc_gpio_write(void *data, int pin_number, u8 byte)
{
struct logical_dev *ldev = (struct logical_dev *)data;
int port, pin;
@@ -263,7 +271,7 @@
outb(val, ldev->base_addr + reg);
}
-void sc_gpio_control(void *data, int pin, u8 mask, u8 ctl)
+static void sc_gpio_control(void *data, int pin, u8 mask, u8 ctl)
{
struct logical_dev *ldev = (struct logical_dev *)data;
u8 cfg, ev;
@@ -302,9 +310,3 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Evgeniy Polyakov <[email protected]>");
MODULE_DESCRIPTION("Driver for GPIO logical device.");
-
-EXPORT_SYMBOL(sc_gpio_activate);
-EXPORT_SYMBOL(sc_gpio_read);
-EXPORT_SYMBOL(sc_gpio_write);
-EXPORT_SYMBOL(sc_gpio_control);
-EXPORT_SYMBOL(sc_gpio_pin_select);
diff -ru linux-2.6/drivers/superio.orig/sc_gpio.h
linux-2.6/drivers/superio/sc_gpio.h
--- linux-2.6/drivers/superio.orig/sc_gpio.h 2005-01-24
17:07:28.305778208 +0300
+++ linux-2.6/drivers/superio/sc_gpio.h 2005-01-24 17:10:26.750650464
+0300
@@ -40,13 +40,6 @@
#define SIO_GPIO_CONF_EVENT_POLAR_RIS (1 << 5)
#define SIO_GPIO_CONF_DEBOUNCE (1 << 6)
-int sc_gpio_activate(void *);
-u8 sc_gpio_read(void *, int);
-void sc_gpio_write(void *, int, u8);
-void sc_gpio_control(void *, int, u8, u8);
-void sc_gpio_pin_select(void *, int);
-irqreturn_t sc_gpio_interrupt(int, void *, struct pt_regs *);
-
struct gpio_pin
{
u8 state;
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
> bk-i2c.patch
This contains two new subsystems, both aren't exactly the nicest code
on earth and one isn't even explained what it is. And both aren't
really i2c-related.
Greg, any chance you could stop funneling new tasteless code in through
the backdoor?
On Mon, 24 Jan 2005 14:41:49 +0100
Brice Goglin <[email protected]> wrote:
> Brice Goglin a ?crit :
> > Andrew Morton a ?crit :
> >
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> >>
> >>
> >>
> >> - Lots of updates and fixes all over the place.
> >
> >
> > Hi Andrew,
> >
> > X does not work anymore when using DRI on my Compaq Evo N600c (Radeon
> > Mobility M6 LY).
> > My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel
> > modules.
> >
> > Instead of the usual gdm window, I get a black or noisy screen
> > (remaining image parts of
> > last working session). The mouse pointer works. Sysrq works. But
> > Caps-lock doesn't work.
> > The machine pings but I can't ssh.
> >
> > I don't know exactly what's happening. I don't see anything interesting
> > in dmesg.
>
> Thanks to Benoit who found this at the end of dmesg:
> agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
> agpgart: Couldn't find an AGP VGA controller.
>
> while Linus' 2.6.11-rc2 says:
> agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
> agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
> agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
>
> Regards,
> Brice
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
the same problem here.... with the nvidia-driver .....seems that AGP is totally brocken.
Jan 24 13:50:09 hal9000 agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
Jan 24 13:50:09 hal9000 agpgart: Couldn't find an AGP VGA controller.
--
-----------------------------------------------------------------------------
"Real Programmers consider "what you see is what you get" to
be just as bad a concept in Text Editors as it is in women.
No, the Real Programmer wants a "you asked for it, you got
it" text editor -- complicated, cryptic, powerful,
unforgiving, dangerous."
-----------------------------------------------------------------------------
On Mon, Jan 24, 2005 at 04:11:13PM +0100, Benoit Boissinot wrote:
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> >
> >
> > - Lots of updates and fixes all over the place.
> >
> >
> > Changes since 2.6.11-rc1-mm2:
> >
> > [snip]
> >
> > +kernel-forkc-make-mm_cachep-static.patch
> >
> > Little fixes.
> >
> >
> It breaks compilation with gcc-4.0
>
> kernel/fork.c:1249: error: static declaration of ???mm_cachep??? follows non-static declaration
> include/linux/slab.h:117: error: previous declaration of ???mm_cachep??? was here
> make[1]: *** [kernel/fork.o] Error 1
> make: *** [kernel] Error 2
>...
Ups, yes, thanks. This was my fault.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Jan 24, 2005 at 02:57:17PM +0100, Gerd Knorr wrote:
> On Mon, Jan 24, 2005 at 12:17:13PM +0100, Adrian Bunk wrote:
> > On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > >...
> > > +v4l-saa7134-module.patch
> >
> > This patch broke compilation with CONFIG_MODULES=n:
> >
> > drivers/media/video/saa7134/saa7134-core.c: In function `pending_call':
> > drivers/media/video/saa7134/saa7134-core.c:234: error: `MODULE_STATE_LIVE' undeclared (first use in this function)
>
> The patch below should fix this.
Not completely:
<-- snip -->
...
CC drivers/media/video/saa7134/saa7134-core.o
drivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':
drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress' undeclared (first use in this function)
drivers/media/video/saa7134/saa7134-core.c:997: error: (Each undeclared identifier is reported only once
drivers/media/video/saa7134/saa7134-core.c:997: error: for each function it appears in.)
drivers/media/video/saa7134/saa7134-core.c:1000: error: `need_dvb' undeclared (first use in this function)
make[4]: *** [drivers/media/video/saa7134/saa7134-core.o] Error 1
<-- snip -->
> Gerd
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>
>
> - Lots of updates and fixes all over the place.
>
>
> Changes since 2.6.11-rc1-mm2:
>
> [snip]
>
> +kernel-forkc-make-mm_cachep-static.patch
>
> Little fixes.
>
>
It breaks compilation with gcc-4.0
kernel/fork.c:1249: error: static declaration of ‘mm_cachep’ follows non-static declaration
include/linux/slab.h:117: error: previous declaration of ‘mm_cachep’ was here
make[1]: *** [kernel/fork.o] Error 1
make: *** [kernel] Error 2
Signed-off-by: Benoit Boissinot <[email protected]>
--- linux/include/linux/slab.h 2005-01-24 11:36:33.000000000 +0100
+++ linux/include/linux/slab.h.new 2005-01-24 12:24:46.000000000 +0100
@@ -114,7 +114,6 @@ extern int FASTCALL(kmem_ptr_validate(km
/* System wide caches */
extern kmem_cache_t *vm_area_cachep;
-extern kmem_cache_t *mm_cachep;
extern kmem_cache_t *names_cachep;
extern kmem_cache_t *files_cachep;
extern kmem_cache_t *filp_cachep;
--- linux-clean/kernel/fork.c 2005-01-24 12:44:48.000000000 +0100
+++ linux/kernel/fork.c 2005-01-24 12:38:27.000000000 +0100
@@ -81,6 +81,24 @@ int nr_processes(void)
static kmem_cache_t *task_struct_cachep;
#endif
+/* SLAB cache for signal_struct structures (tsk->signal) */
+kmem_cache_t *signal_cachep;
+
+/* SLAB cache for sighand_struct structures (tsk->sighand) */
+kmem_cache_t *sighand_cachep;
+
+/* SLAB cache for files_struct structures (tsk->files) */
+kmem_cache_t *files_cachep;
+
+/* SLAB cache for fs_struct structures (tsk->fs) */
+kmem_cache_t *fs_cachep;
+
+/* SLAB cache for vm_area_struct structures */
+kmem_cache_t *vm_area_cachep;
+
+/* SLAB cache for mm_struct structures (tsk->mm) */
+static kmem_cache_t *mm_cachep;
+
void free_task(struct task_struct *tsk)
{
free_thread_info(tsk->thread_info);
@@ -1230,24 +1248,6 @@ long do_fork(unsigned long clone_flags,
return pid;
}
-/* SLAB cache for signal_struct structures (tsk->signal) */
-kmem_cache_t *signal_cachep;
-
-/* SLAB cache for sighand_struct structures (tsk->sighand) */
-kmem_cache_t *sighand_cachep;
-
-/* SLAB cache for files_struct structures (tsk->files) */
-kmem_cache_t *files_cachep;
-
-/* SLAB cache for fs_struct structures (tsk->fs) */
-kmem_cache_t *fs_cachep;
-
-/* SLAB cache for vm_area_struct structures */
-kmem_cache_t *vm_area_cachep;
-
-/* SLAB cache for mm_struct structures (tsk->mm) */
-static kmem_cache_t *mm_cachep;
-
void __init proc_caches_init(void)
{
sighand_cachep = kmem_cache_create("sighand_cache",
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>
>
> - Lots of updates and fixes all over the place.
>
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
>
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
>
>
>
> Changes since 2.6.11-rc1-mm2:
>
>
> bk-netdev.patch
Without the following patch, it doesn't compile with ip_conntrack and
without ip_nat.
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34:
include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has incomplete type
include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized':
include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC' undeclared (first use in this function)
regards,
Benoit
Signed-off-by: Benoit Boissinot <[email protected]>
--- linux-clean/include/linux/netfilter_ipv4/ip_conntrack.h 2005-01-24 12:44:29.000000000 +0100
+++ linux/include/linux/netfilter_ipv4/ip_conntrack.h 2005-01-24 13:05:44.000000000 +0100
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
+#ifdef CONFIG_IP_NF_NAT_NEEDED
static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
enum ip_nat_manip_type manip)
{
@@ -308,5 +309,6 @@ static inline int ip_nat_initialized(str
return test_bit(IPS_SRC_NAT_DONE_BIT, &conntrack->status);
return test_bit(IPS_DST_NAT_DONE_BIT, &conntrack->status);
}
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
#endif /* __KERNEL__ */
#endif /* _IP_CONNTRACK_H */
It seems noone who reviewed the SuperIO patches noticed that there are
now two modules "scx200" in the kernel...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, 24 Jan 2005 18:54:49 +0100
Adrian Bunk <[email protected]> wrote:
> It seems noone who reviewed the SuperIO patches noticed that there are
> now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced),
so I do not see any problem here.
Only one of them can be loaded in a time.
So what does exactly bother you?
> cu
> Adrian
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Mon, Jan 24, 2005 at 09:43:36PM +0300, Evgeniy Polyakov wrote:
> On Mon, 24 Jan 2005 18:54:49 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > It seems noone who reviewed the SuperIO patches noticed that there are
> > now two modules "scx200" in the kernel...
>
> They are almost mutually exlusive(SuperIO contains more advanced),
> so I do not see any problem here.
The Kconfig files allow building both modular at the same time.
> Only one of them can be loaded in a time.
You are assuming the module support was in able to correctly handle two
modules with the same name...
> So what does exactly bother you?
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.11-rc2-mm1; fi
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_base
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_configure
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_shadow
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_base
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_configure
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_shadow
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
From: Evgeniy Polyakov <[email protected]>
Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> On Mon, 24 Jan 2005 18:54:49 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > It seems noone who reviewed the SuperIO patches noticed that there are
> > now two modules "scx200" in the kernel...
>
> They are almost mutually exlusive(SuperIO contains more advanced),
> so I do not see any problem here.
> Only one of them can be loaded in a time.
>
> So what does exactly bother you?
>
lsmod in bugreports giving unspecific results, for example.
Kind regards,
Jurriaan
--
"So you believe."
Jewel ATerafin shrugged. "I have more than belief, but I don't have a
pressing need to convince you of anything."
Michelle West - Sea of Sorrows.
Debian (Unstable) GNU/Linux 2.6.10-mm1 2x6078 bogomips load 0.52
On Mon, Jan 24, 2005 at 12:56:58PM +0100, Brice Goglin wrote:
> X does not work anymore when using DRI on my Compaq Evo N600c (Radeon
> Mobility M6 LY).
> My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel
> modules.
My fault. I'm looking into it.
Drop the agpgart-bk update for now.
Dave
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>
>
> - Lots of updates and fixes all over the place.
>
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
>
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
>
>
>
> Changes since 2.6.11-rc1-mm2:
>
> [snip]
>
> +matroxfb_basec-make-some-code-static.patch
>
> Little fixes.
>
It breaks compilation with gcc-4.0
The patch below correct it.
regards,
Benoit
Signed-off-by: Benoit Boissinot <[email protected]>
--- linux-clean/drivers/video/matrox/matroxfb_base.h 2005-01-24 12:44:43.000000000 +0100
+++ linux-test/drivers/video/matrox/matroxfb_base.h 2005-01-24 19:49:29.000000000 +0100
@@ -764,7 +764,6 @@ void matroxfb_unregister_driver(struct m
#define matroxfb_DAC_unlock_irqrestore(flags) spin_unlock_irqrestore(&ACCESS_FBINFO(lock.DAC),flags)
extern void matroxfb_DAC_out(CPMINFO int reg, int val);
extern int matroxfb_DAC_in(CPMINFO int reg);
-extern struct list_head matroxfb_list;
extern void matroxfb_var2my(struct fb_var_screeninfo* fvsi, struct my_timming* mt);
extern int matroxfb_wait_for_sync(WPMINFO u_int32_t crtc);
extern int matroxfb_enable_irq(WPMINFO int reenable);
On Mon, 24 Jan 2005 19:29:26 +0100
Adrian Bunk <[email protected]> wrote:
> On Mon, Jan 24, 2005 at 09:43:36PM +0300, Evgeniy Polyakov wrote:
> > On Mon, 24 Jan 2005 18:54:49 +0100
> > Adrian Bunk <[email protected]> wrote:
> >
> > > It seems noone who reviewed the SuperIO patches noticed that there are
> > > now two modules "scx200" in the kernel...
> >
> > They are almost mutually exlusive(SuperIO contains more advanced),
> > so I do not see any problem here.
>
> The Kconfig files allow building both modular at the same time.
>
> > Only one of them can be loaded in a time.
>
> You are assuming the module support was in able to correctly handle two
> modules with the same name...
>
> > So what does exactly bother you?
>
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.11-rc2-mm1; fi
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_base
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_configure
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_shadow
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_base
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_configure
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_shadow
Sorry, I can not buy it.
Above symbols are defined in old scx200 driver, and I it is depmod
who tries to get them from superio.
I definitely sure that it must be solved on the other layers.
But nevertheless, obviously it is much easier to change superio's scx200 name
and I will do it.
>
> cu
> Adrian
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Mon, 24 Jan 2005 19:41:11 +0100
Jurriaan <[email protected]> wrote:
> From: Evgeniy Polyakov <[email protected]>
> Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> > On Mon, 24 Jan 2005 18:54:49 +0100
> > Adrian Bunk <[email protected]> wrote:
> >
> > > It seems noone who reviewed the SuperIO patches noticed that there are
> > > now two modules "scx200" in the kernel...
> >
> > They are almost mutually exlusive(SuperIO contains more advanced),
> > so I do not see any problem here.
> > Only one of them can be loaded in a time.
> >
> > So what does exactly bother you?
> >
> lsmod in bugreports giving unspecific results, for example.
If you load scx200 from superio subsystem, then obviously you can not
use old i2c/acb modules which require old scx200.
And vice versa.
One needs to load exactly what he wants.
> Kind regards,
> Jurriaan
> --
> "So you believe."
> Jewel ATerafin shrugged. "I have more than belief, but I don't have a
> pressing need to convince you of anything."
> Michelle West - Sea of Sorrows.
> Debian (Unstable) GNU/Linux 2.6.10-mm1 2x6078 bogomips load 0.52
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Mon, Jan 24, 2005 at 10:19:29PM +0300, Evgeniy Polyakov wrote:
> On Mon, 24 Jan 2005 19:29:26 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > On Mon, Jan 24, 2005 at 09:43:36PM +0300, Evgeniy Polyakov wrote:
> > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > Adrian Bunk <[email protected]> wrote:
> > >
> > > > It seems noone who reviewed the SuperIO patches noticed that there are
> > > > now two modules "scx200" in the kernel...
> > >
> > > They are almost mutually exlusive(SuperIO contains more advanced),
> > > so I do not see any problem here.
> >
> > The Kconfig files allow building both modular at the same time.
> >
> > > Only one of them can be loaded in a time.
> >
> > You are assuming the module support was in able to correctly handle two
> > modules with the same name...
> >
> > > So what does exactly bother you?
> >
> > if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.11-rc2-mm1; fi
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_base
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_configure
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_shadow
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_base
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_configure
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_shadow
>
> Sorry, I can not buy it.
> Above symbols are defined in old scx200 driver, and I it is depmod
> who tries to get them from superio.
More exactly, "make modules_install" does install only one of the two
drivers.
> I definitely sure that it must be solved on the other layers.
>...
Two modules with the same name are simply a _very_ bad idea.
Even if they weren't allowed to be compiled at the same time, they
should be named differently or it will cause much confusion for
everyone (or don't you want to see from the output of "lsmod" which of
the two modules is loaded?).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Jan 24, 2005 at 10:23:02PM +0300, Evgeniy Polyakov wrote:
> On Mon, 24 Jan 2005 19:41:11 +0100
> Jurriaan <[email protected]> wrote:
>
> > From: Evgeniy Polyakov <[email protected]>
> > Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > Adrian Bunk <[email protected]> wrote:
> > >
> > > > It seems noone who reviewed the SuperIO patches noticed that there are
> > > > now two modules "scx200" in the kernel...
> > >
> > > They are almost mutually exlusive(SuperIO contains more advanced),
> > > so I do not see any problem here.
> > > Only one of them can be loaded in a time.
> > >
> > > So what does exactly bother you?
> > >
> > lsmod in bugreports giving unspecific results, for example.
>
> If you load scx200 from superio subsystem, then obviously you can not
> use old i2c/acb modules which require old scx200.
> And vice versa.
>
> One needs to load exactly what he wants.
You did not understand what Jurriaan said:
Even if it was working, "lsmod" would not be able to tell which of the
two modules was loaded.
This would cause much headache for many people.
> > Kind regards,
> > Jurriaan
>
> Evgeniy Polyakov
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Jan 24, 2005 at 07:58:23PM +0100, Benoit Boissinot wrote:
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> >
> >
> > - Lots of updates and fixes all over the place.
> >
> > - On my test box there is no flashing cursor on the vga console. Known bug,
> > please don't report it.
> >
> > Binary searching shows that the bug was introduced by
> > cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
> >
> >
> >
> > Changes since 2.6.11-rc1-mm2:
> >
> > [snip]
> >
> > +matroxfb_basec-make-some-code-static.patch
> >
> > Little fixes.
> >
> It breaks compilation with gcc-4.0
>
> The patch below correct it.
This patch is correct, too.
I do grep for the symbols I'm making static, but it seems I have to
sharpen my eyes...
> regards,
>
> Benoit
>...
Sorry
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, 24 Jan 2005 20:05:46 +0100
Adrian Bunk <[email protected]> wrote:
> On Mon, Jan 24, 2005 at 10:23:02PM +0300, Evgeniy Polyakov wrote:
> > On Mon, 24 Jan 2005 19:41:11 +0100
> > Jurriaan <[email protected]> wrote:
> >
> > > From: Evgeniy Polyakov <[email protected]>
> > > Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> > > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > > Adrian Bunk <[email protected]> wrote:
> > > >
> > > > > It seems noone who reviewed the SuperIO patches noticed that there are
> > > > > now two modules "scx200" in the kernel...
> > > >
> > > > They are almost mutually exlusive(SuperIO contains more advanced),
> > > > so I do not see any problem here.
> > > > Only one of them can be loaded in a time.
> > > >
> > > > So what does exactly bother you?
> > > >
> > > lsmod in bugreports giving unspecific results, for example.
> >
> > If you load scx200 from superio subsystem, then obviously you can not
> > use old i2c/acb modules which require old scx200.
> > And vice versa.
> >
> > One needs to load exactly what he wants.
>
> You did not understand what Jurriaan said:
>
> Even if it was working, "lsmod" would not be able to tell which of the
> two modules was loaded.
>
> This would cause much headache for many people.
Module is just a piece of code, or programm if someone may think.
And there no problems when we type
$ ps
and see only "aterm", if someone wants to know what exactly means "aterm",
one can run ps axufw.
And even with the case of lsmod: one can see that scx200 will or will not
depend on superio, and that will explain everything.
> > > Kind regards,
> > > Jurriaan
> >
> > Evgeniy Polyakov
>
> cu
> Adrian
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Mon, 24 Jan 2005 20:03:20 +0100
Adrian Bunk <[email protected]> wrote:
> On Mon, Jan 24, 2005 at 10:19:29PM +0300, Evgeniy Polyakov wrote:
> > On Mon, 24 Jan 2005 19:29:26 +0100
> > Adrian Bunk <[email protected]> wrote:
> >
> > > On Mon, Jan 24, 2005 at 09:43:36PM +0300, Evgeniy Polyakov wrote:
> > > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > > Adrian Bunk <[email protected]> wrote:
> > > >
> > > > > It seems noone who reviewed the SuperIO patches noticed that there are
> > > > > now two modules "scx200" in the kernel...
> > > >
> > > > They are almost mutually exlusive(SuperIO contains more advanced),
> > > > so I do not see any problem here.
> > >
> > > The Kconfig files allow building both modular at the same time.
> > >
> > > > Only one of them can be loaded in a time.
> > >
> > > You are assuming the module support was in able to correctly handle two
> > > modules with the same name...
> > >
> > > > So what does exactly bother you?
> > >
> > > if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.11-rc2-mm1; fi
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_base
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_configure
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_shadow
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_base
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_configure
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_shadow
> >
> > Sorry, I can not buy it.
> > Above symbols are defined in old scx200 driver, and I it is depmod
> > who tries to get them from superio.
>
> More exactly, "make modules_install" does install only one of the two
> drivers.
>
> > I definitely sure that it must be solved on the other layers.
> >...
>
> Two modules with the same name are simply a _very_ bad idea.
>
> Even if they weren't allowed to be compiled at the same time, they
> should be named differently or it will cause much confusion for
> everyone (or don't you want to see from the output of "lsmod" which of
> the two modules is loaded?).
I do not agree with you, Adrian, but I will not contend.
As I say, noone protects against the same program names and there are
mechnisms to differ modules by simply looking in lsmod output.
Noone can damage systrem by loading "wrong" module.
So I still do not see problems here.
As I say I will change superio scx200 name since it is easier than
flood about unmatched points of view.
I will send patch through Greg and Andrew later.
Thank you, Adrian, for your comments.
> cu
> Adrian
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Mon, 24 Jan 2005 22:39:25 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> On Mon, 24 Jan 2005 20:05:46 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > On Mon, Jan 24, 2005 at 10:23:02PM +0300, Evgeniy Polyakov wrote:
> > > On Mon, 24 Jan 2005 19:41:11 +0100
> > > Jurriaan <[email protected]> wrote:
> > >
> > > > From: Evgeniy Polyakov <[email protected]>
> > > > Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> > > > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > > > Adrian Bunk <[email protected]> wrote:
> > > > >
> > > > > > It seems noone who reviewed the SuperIO patches noticed that there are
> > > > > > now two modules "scx200" in the kernel...
> > > > >
> > > > > They are almost mutually exlusive(SuperIO contains more advanced),
> > > > > so I do not see any problem here.
> > > > > Only one of them can be loaded in a time.
> > > > >
> > > > > So what does exactly bother you?
> > > > >
> > > > lsmod in bugreports giving unspecific results, for example.
> > >
> > > If you load scx200 from superio subsystem, then obviously you can not
> > > use old i2c/acb modules which require old scx200.
> > > And vice versa.
> > >
> > > One needs to load exactly what he wants.
> >
> > You did not understand what Jurriaan said:
> >
> > Even if it was working, "lsmod" would not be able to tell which of the
> > two modules was loaded.
> >
> > This would cause much headache for many people.
>
>
> Module is just a piece of code, or programm if someone may think.
> And there no problems when we type
> $ ps
> and see only "aterm", if someone wants to know what exactly means "aterm",
> one can run ps axufw.
> And even with the case of lsmod: one can see that scx200 will or will not
> depend on superio, and that will explain everything.
>
There are so many problems and ambiguites with having non-unique
module names it is not even funny:
- when I modprobe scx200 what willI get?
- if I want to blacklist one of the modules (let's say hotplug) how do
I do that?
- lsmod (with everything else compiled in, possible?) - which one is loadded?
...etc, etc...
--
Dmitry
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>
>
> - Lots of updates and fixes all over the place.
>
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
>
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
>
> +nfsacl-infrastructure-and-server-side-of-nfsacl.patch
>
> ACLs for ther NFS client.
>
Patch below fix a typo.
--- linux-clean/fs/nfsd/nfs3proc.c 2005-01-24 12:44:44.000000000 +0100
+++ linux-test/fs/nfsd/nfs3proc.c 2005-01-24 18:22:18.000000000 +0100
@@ -813,7 +813,7 @@ struct svc_procedure nfsd_acl_procedure
struct svc_version nfsd_acl_version3 = {
.vs_vers = 3,
.vs_nproc = 3,
- .vs_proc nfsd_acl_procedures3,
+ .vs_proc = nfsd_acl_procedures3,
.vs_dispatch = nfsd_dispatch,
.vs_xdrsize = NFS3_SVC_XDRSIZE,
};
On Mon, 24 Jan 2005 14:32:19 -0500
Dmitry Torokhov <[email protected]> wrote:
> > > > > lsmod in bugreports giving unspecific results, for example.
> > > >
> > > > If you load scx200 from superio subsystem, then obviously you can not
> > > > use old i2c/acb modules which require old scx200.
> > > > And vice versa.
> > > >
> > > > One needs to load exactly what he wants.
> > >
> > > You did not understand what Jurriaan said:
> > >
> > > Even if it was working, "lsmod" would not be able to tell which of the
> > > two modules was loaded.
> > >
> > > This would cause much headache for many people.
> >
> >
> > Module is just a piece of code, or programm if someone may think.
> > And there no problems when we type
> > $ ps
> > and see only "aterm", if someone wants to know what exactly means "aterm",
> > one can run ps axufw.
> > And even with the case of lsmod: one can see that scx200 will or will not
> > depend on superio, and that will explain everything.
Before I murdered in my bad, I want to say, that I agree that changing
scx200 into scx is easier and probably better idea.
And I will do it(I am doing it right now),
> There are so many problems and ambiguites with having non-unique
> module names it is not even funny:
> - when I modprobe scx200 what willI get?
Sorry or answering with a question, but what will you run when typing
aterm in your shell?
Is it simlink to xterm, or /bin/aterm, or /usr/local/bin/aterm?
It depends on $PATH, with modprobe it depends on something else...
Bug? Probably. Feature? Maybe. I do not complain.
> - if I want to blacklist one of the modules (let's say hotplug) how do
> I do that?
When you want to run exact program, you type the whole path, no?
Load exact modules with known-to-be-good pathes.
I can hack shell script over modprobe to warn if there are several modules
with the same name, and ask exact path or something...
> - lsmod (with everything else compiled in, possible?) - which one is loadded?
/sbin/modinfo shows enough information about module to distingiush one from another.
> ...etc, etc...
I understand your point of view, and can say, that the same module names are not
very convenient and some times even confused, but it is not a cause to kill
such idea and mark it as badly broken.
It is right thing, it just currently has some nitpicks, nothing more, noone complains
that modules for different kernel versions have the same name, but different
elf sections in it, it is of course different things, but they do have the same
roots in common.
As I have beed told in private,
"what is technically possible, is not necessarily practically useful.", probably
it is the essence.
Thank you for discussion.
> --
> Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Hi!
The new ioctl code in fs/compat.c can be streamlined a little
using the compat hash instead of an explicit switch statement.
The attached patch is against 2.6.11-rc2-bk2.
Andi, could you please comment? Does this make sence?
Signed-off-by: Michael S. Tsirkin <[email protected]>
diff -rup linux-2.6.10/fs/compat.c linux-2.6.10-rc2-bk2/fs/compat.c
--- linux-2.6.10/fs/compat.c 2005-01-24 21:47:17.252499536 +0200
+++ linux-2.6.10-rc2-bk2/fs/compat.c 2005-01-24 22:06:00.254777240 +0200
@@ -439,37 +439,10 @@ asmlinkage long compat_sys_ioctl(unsigne
if (!filp)
goto out;
- /*
- * To allow the compat_ioctl handlers to be self contained
- * we need to check the common ioctls here first.
- * Just handle them with the standard handlers below.
- */
- switch (cmd) {
- case FIOCLEX:
- case FIONCLEX:
- case FIONBIO:
- case FIOASYNC:
- case FIOQSIZE:
- break;
-
- case FIBMAP:
- case FIGETBSZ:
- case FIONREAD:
- if (S_ISREG(filp->f_dentry->d_inode->i_mode))
- break;
- /*FALL THROUGH*/
-
- default:
- if (filp->f_op && filp->f_op->compat_ioctl) {
- error = filp->f_op->compat_ioctl(filp, cmd, arg);
- if (error != -ENOIOCTLCMD)
- goto out_fput;
- }
-
- if (!filp->f_op ||
- (!filp->f_op->ioctl && !filp->f_op->unlocked_ioctl))
- goto do_ioctl;
- break;
+ if (filp->f_op && filp->f_op->compat_ioctl) {
+ error = filp->f_op->compat_ioctl(filp, cmd, arg);
+ if (error != -ENOIOCTLCMD)
+ goto out_fput;
}
/* When register_ioctl32_conversion is finally gone remove
@@ -509,7 +482,7 @@ asmlinkage long compat_sys_ioctl(unsigne
}
up_read(&ioctl32_sem);
- do_ioctl:
+
error = sys_ioctl(fd, cmd, arg);
out_fput:
fput_light(filp, fput_needed);
diff -rup linux-2.6.10/fs/ioctl.c linux-2.6.10-rc2-bk2/fs/ioctl.c
--- linux-2.6.10/fs/ioctl.c 2005-01-24 21:47:17.400477040 +0200
+++ linux-2.6.10-rc2-bk2/fs/ioctl.c 2005-01-24 22:05:38.346107864 +0200
@@ -80,7 +80,7 @@ static int file_ioctl(struct file *filp,
/*
* When you add any new common ioctls to the switches above and below
- * please update compat_sys_ioctl() too.
+ * please update compat_ioctl.h too.
*/
asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
{
diff -rup linux-2.6.10/include/linux/compat_ioctl.h linux-2.6.10-rc2-bk2/include/linux/compat_ioctl.h
--- linux-2.6.10/include/linux/compat_ioctl.h 2005-01-24 21:47:21.486855816 +0200
+++ linux-2.6.10-rc2-bk2/include/linux/compat_ioctl.h 2005-01-24 22:06:22.349418344 +0200
@@ -10,6 +10,15 @@
#define ULONG_IOCTL(cmd) HANDLE_IOCTL((cmd),(ioctl_trans_handler_t)sys_ioctl)
#endif
+/* Common stuff */
+HANDLE_IOCTL(FIOCLEX)
+HANDLE_IOCTL(FIONCLEX)
+HANDLE_IOCTL(FIONBIO)
+HANDLE_IOCTL(FIOASYNC)
+HANDLE_IOCTL(FIOQSIZE)
+HANDLE_IOCTL(FIBMAP)
+HANDLE_IOCTL(FIGETBSZ)
+HANDLE_IOCTL(FIONREAD)
/* Big T */
COMPATIBLE_IOCTL(TCGETA)
COMPATIBLE_IOCTL(TCSETA)
--
I dont speak for Mellanox.
On Mon, Jan 24, 2005 at 01:52:58PM -0500, Dave Jones wrote:
> On Mon, Jan 24, 2005 at 12:56:58PM +0100, Brice Goglin wrote:
> > X does not work anymore when using DRI on my Compaq Evo N600c (Radeon
> > Mobility M6 LY).
> > My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel
> > modules.
>
> My fault. I'm looking into it.
> Drop the agpgart-bk update for now.
Here's the most obvious bug fixed. There still seems to be
something wrong however. It only successfully boots 50% of the
time for me, (it reboots when starting X otherwise), and when
it does boot, I get a flood of ...
Warning: kfree_skb on hard IRQ cf7b5800
Warning: kfree_skb on hard IRQ cf7b5800
Warning: kfree_skb on hard IRQ cf7b5800
I think there may be some stupid memory corruptor bug in there still.
Dave
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/01/24 15:37:57-05:00 [email protected]
# [AGPGART] Fix stupid thinko in device discovery.
#
# Should fix the 'cant find AGP VGA controller' warnings.
#
# Signed-off-by: Dave Jones <[email protected]>
diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
--- a/drivers/char/agp/generic.c 2005-01-24 15:38:26 -05:00
+++ b/drivers/char/agp/generic.c 2005-01-24 15:38:26 -05:00
@@ -626,7 +626,7 @@
u32 vga_agpstat;
while (!cap_ptr) {
- device = pci_get_class(PCI_CLASS_DISPLAY_VGA, device);
+ device = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, device);
if (!device) {
printk (KERN_INFO PFX "Couldn't find an AGP VGA controller.\n");
return 0;
On Mon, 24 Jan 2005 20:33:53 +0000
Christoph Hellwig <[email protected]> wrote:
> On Mon, Jan 24, 2005 at 06:54:49PM +0100, Adrian Bunk wrote:
> > It seems noone who reviewed the SuperIO patches noticed that there are
> > now two modules "scx200" in the kernel...
>
> Did anyone review them?
As I said it is completely my fault, I pressed on Greg,
since patch several month laid after testing and people often asked
about GPIO in various SuperIO chips.
Patches were sent into lm_sensors@ mail list some time ago
and code itself did not meet any objections.
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Christoph Hellwig <[email protected]> wrote:
>
> > +posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
>
> umm, this adds extreme obsfucation. Roland, please try to follow normal
> Linux style, thanks.
Best cc Roland - not everyone follows linux-kernel.
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>
>
> - Lots of updates and fixes all over the place.
>
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
>
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
>
>
The patch below fixes the compilation of the tftp nat module
net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0):net/ipv4/netfilter/ip_nat_tftp.c:44: multiple definition of `ip_nat_tftp_hook'
net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0):net/ipv4/netfilter/ip_conntrack_tftp.c:49: first defined here
make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1
make[2]: *** [net/ipv4/netfilter] Error 2
make[1]: *** [net/ipv4] Error 2
make: *** [net] Error 2
Signed-off-by: Benoit Boissinot <[email protected]>
--- linux-clean/include/linux/netfilter_ipv4/ip_conntrack_tftp.h 2005-01-24 12:44:29.000000000 +0100
+++ linux-test/include/linux/netfilter_ipv4/ip_conntrack_tftp.h 2005-01-24 21:11:05.000000000 +0100
@@ -13,8 +13,8 @@ struct tftphdr {
#define TFTP_OPCODE_ACK 4
#define TFTP_OPCODE_ERROR 5
-unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
- enum ip_conntrack_info ctinfo,
- struct ip_conntrack_expect *exp);
+extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
+ enum ip_conntrack_info ctinfo,
+ struct ip_conntrack_expect *exp);
#endif /* _IP_CT_TFTP */
Dave Jones a ?crit :
> Here's the most obvious bug fixed. There still seems to be
> something wrong however. It only successfully boots 50% of the
> time for me, (it reboots when starting X otherwise), and when
> it does boot, I get a flood of ...
> Warning: kfree_skb on hard IRQ cf7b5800
> Warning: kfree_skb on hard IRQ cf7b5800
> Warning: kfree_skb on hard IRQ cf7b5800
>
> I think there may be some stupid memory corruptor bug in there still.
>
> Dave
Thanks, your patch makes X work again with DRI.
Actually, it successfully booted 100% of the time here.
I tried 6 or 7 times without seeing any problem like yours.
Let me know if you want me to try something special.
Brice
On Mon, Jan 24, 2005 at 06:54:49PM +0100, Adrian Bunk wrote:
> It seems noone who reviewed the SuperIO patches noticed that there are
> now two modules "scx200" in the kernel...
Did anyone review them?
On Mon, Jan 24, 2005 at 06:54:49PM +0100, Adrian Bunk wrote:
> It seems noone who reviewed the SuperIO patches noticed that there are
> now two modules "scx200" in the kernel...
Sorry about this. Andrew warning me about this bug, and I saw it myself
with the depmod errors. I'll take Evgeniy's patch for my tree and it
should show up in the next -mm release.
And as for the "these patches have never been reviewed" comments, that's
why I put them in my tree, and have them show up in -mm. It's getting
them a wider exposure and finding out these kinds of issues. So the
process is working properly :)
thanks,
greg k-h
On Mon, Jan 24, 2005 at 01:34:42PM -0800, Greg KH wrote:
> And as for the "these patches have never been reviewed" comments, that's
> why I put them in my tree, and have them show up in -mm. It's getting
> them a wider exposure and finding out these kinds of issues. So the
> process is working properly :)
It would be a lot more productive to follow the normal rules, though.
That is posting them on lkml as properly split up patches, and with
proper descriptions of what they're doing.
On Mon, Jan 24, 2005 at 12:12:26PM +0000, Christoph Hellwig wrote:
> > +i4l-new-hfc_usb-driver-version.patch
>
> this drivers wants:
>
> - update for Documentation/CodingStyle
agree, I only take the patch from chip manufacturer and
test compiling and working with my hardware and do not look at code style
yet.
> - conversion to proper pci API
??? the driver is not PCI related at all
--
Karsten Keil
SuSE Labs
ISDN development
On Mon, Jan 24, 2005 at 09:36:24PM +0100, Karsten Keil wrote:
> > - conversion to proper pci API
>
> ??? the driver is not PCI related at all
Sorry, this was actually a comment for i4l-hfc-4s-and-hfc-8s-driver.patch.
On Mon, 24 Jan 2005 21:36:24 +0100, Karsten Keil <[email protected]> wrote:
> On Mon, Jan 24, 2005 at 12:12:26PM +0000, Christoph Hellwig wrote:
> > > +i4l-new-hfc_usb-driver-version.patch
> >
> > this drivers wants:
> >
> > - update for Documentation/CodingStyle
>
> agree, I only take the patch from chip manufacturer and
> test compiling and working with my hardware and do not look at code style
> yet.
>
> > - conversion to proper pci API
>
> ??? the driver is not PCI related at all
it seems that hch wanted to also mention this patch:
i4l-hfc-4s-and-hfc-8s-driver.patch
and it is indeed a very ugly one...
Adrian Bunk wrote:
> The following compile error comes from Linus' tree:
>
> <-- snip -->
>
> ...
> LD .tmp_vmlinux1
> drivers/built-in.o(.bss+0xd50e4): multiple definition of `debug'
> arch/i386/kernel/built-in.o(.text+0x2e4c): first defined here
> make: *** [.tmp_vmlinux1] Error 1
>
> <-- snip -->
>
>
> The offender is in drivers/media/dvb/dibusb/dvb-dibusb-core.c:
>
> "debug" is not a good name for a global variable...
I've sorted this out with Patrick. The attached patch cleans up
various aspects of dibusb module argument handling, so it's a bit
larger than just renaming "debug".
Andrew, could you please make sure this patch and
dib3000mc-build-fix.patch (from rc2-mm1) will be
merged into Linus tree before 2.6.11? Or should I
submit it to Linus seperately?
Thanks,
Johannes
diff -rupN linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-core.c
--- linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c 2005-01-24 23:31:05.000000000 +0100
+++ linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-core.c 2005-01-24 23:16:27.000000000 +0100
@@ -27,17 +27,19 @@
#include <linux/moduleparam.h>
/* debug */
-#ifdef CONFIG_DVB_DIBCOM_DEBUG
-int debug;
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, "set debugging level (1=info,2=xfer,4=alotmore,8=ts,16=err,32=rc (|-able)).");
+int dvb_dibusb_debug;
+module_param_named(debug, dvb_dibusb_debug, int, 0644);
+MODULE_PARM_DESC(debug, "set debugging level (1=info,2=xfer,4=alotmore,8=ts,16=err,32=rc (|-able))."
+#ifndef CONFIG_DVB_DIBCOM_DEBUG
+ " (debugging is not enabled)"
#endif
+);
-int pid_parse;
+static int pid_parse;
module_param(pid_parse, int, 0644);
MODULE_PARM_DESC(pid_parse, "enable pid parsing (filtering) when running at USB2.0");
-int rc_query_interval;
+static int rc_query_interval;
module_param(rc_query_interval, int, 0644);
MODULE_PARM_DESC(rc_query_interval, "interval in msecs for remote control query (default: 100; min: 40)");
@@ -410,6 +412,10 @@ static int dibusb_probe(struct usb_inter
dib->udev = udev;
dib->dibdev = dibdev;
+ /* store parameters to structures */
+ dib->rc_query_interval = rc_query_interval;
+ dib->pid_parse = pid_parse;
+
usb_set_intfdata(intf, dib);
ret = dibusb_init(dib);
diff -rupN linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-remote.c linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-remote.c
--- linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-remote.c 2005-01-24 23:31:05.000000000 +0100
+++ linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-remote.c 2005-01-24 18:26:53.000000000 +0100
@@ -143,7 +143,7 @@ static void dibusb_remote_query(void *da
if we're busy. */
dibusb_read_remote_control(dib);
schedule_delayed_work(&dib->rc_query_work,
- msecs_to_jiffies(rc_query_interval));
+ msecs_to_jiffies(dib->rc_query_interval));
}
int dibusb_remote_init(struct usb_dibusb *dib)
@@ -171,11 +171,11 @@ int dibusb_remote_init(struct usb_dibusb
INIT_WORK(&dib->rc_query_work, dibusb_remote_query, dib);
/* Start the remote-control polling. */
- if (rc_query_interval < 40)
- rc_query_interval = 100; /* default */
+ if (dib->rc_query_interval < 40)
+ dib->rc_query_interval = 100; /* default */
- info("schedule remote query interval to %d msecs.",rc_query_interval);
- schedule_delayed_work(&dib->rc_query_work,msecs_to_jiffies(rc_query_interval));
+ info("schedule remote query interval to %d msecs.",dib->rc_query_interval);
+ schedule_delayed_work(&dib->rc_query_work,msecs_to_jiffies(dib->rc_query_interval));
dib->init_state |= DIBUSB_STATE_REMOTE;
diff -rupN linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-usb.c linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-usb.c
--- linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-usb.c 2005-01-24 23:31:05.000000000 +0100
+++ linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-usb.c 2005-01-24 18:26:53.000000000 +0100
@@ -158,7 +158,7 @@ int dibusb_streaming(struct usb_dibusb *
int dibusb_urb_init(struct usb_dibusb *dib)
{
- int ret,i,bufsize;
+ int ret,i,bufsize,def_pid_parse = 1;
/*
* when reloading the driver w/o replugging the device
@@ -210,12 +210,14 @@ int dibusb_urb_init(struct usb_dibusb *d
dib->init_state |= DIBUSB_STATE_URB_SUBMIT;
}
-
- dib->pid_parse = 1;
+ /* dib->pid_parse here contains the value of the module parameter */
+ /* decide if pid parsing can be deactivated:
+ * is possible (by speed) and wanted (by user)
+ */
switch (dib->dibdev->dev_cl->id) {
case DIBUSB2_0:
- if (dib->udev->speed == USB_SPEED_HIGH && !pid_parse) {
- dib->pid_parse = 0;
+ if (dib->udev->speed == USB_SPEED_HIGH && !dib->pid_parse) {
+ def_pid_parse = 0;
info("running at HIGH speed, will deliver the complete TS.");
} else
info("will use pid_parsing.");
@@ -223,6 +225,8 @@ int dibusb_urb_init(struct usb_dibusb *d
default:
break;
}
+ /* from here on it contains the device and user decision */
+ dib->pid_parse = def_pid_parse;
return 0;
}
diff -rupN linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb.h linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb.h
--- linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb.h 2005-01-24 23:31:05.000000000 +0100
+++ linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb.h 2005-01-24 18:26:53.000000000 +0100
@@ -27,31 +27,26 @@
/* debug */
#ifdef CONFIG_DVB_DIBCOM_DEBUG
#define dprintk(level,args...) \
- do { if ((debug & level)) { printk(args); } } while (0)
+ do { if ((dvb_dibusb_debug & level)) { printk(args); } } while (0)
-#define debug_dump(b,l) if (debug) {\
- int i; deb_xfer("%s: %d > ",__FUNCTION__,l); \
+#define debug_dump(b,l) {\
+ int i; \
for (i = 0; i < l; i++) deb_xfer("%02x ", b[i]); \
deb_xfer("\n");\
}
-/* module parameters - declared in -core.c */
-extern int debug;
-
#else
#define dprintk(args...)
#define debug_dump(b,l)
#endif
+extern int dvb_dibusb_debug;
+
/* Version information */
#define DRIVER_VERSION "0.3"
#define DRIVER_DESC "Driver for DiBcom based USB Budget DVB-T device"
#define DRIVER_AUTHOR "Patrick Boettcher, [email protected]"
-/* module parameters - declared in -core.c */
-extern int pid_parse;
-extern int rc_query_interval;
-
#define deb_info(args...) dprintk(0x01,args)
#define deb_xfer(args...) dprintk(0x02,args)
#define deb_alot(args...) dprintk(0x04,args)
@@ -162,7 +157,6 @@ struct usb_dibusb {
int init_state;
int feedcount;
- int pid_parse;
struct dib_fe_xfer_ops xfer_ops;
struct dibusb_tuner *tuner;
@@ -196,6 +190,10 @@ struct usb_dibusb {
struct input_dev rc_input_dev;
struct work_struct rc_query_work;
int rc_input_event;
+
+ /* module parameters */
+ int pid_parse;
+ int rc_query_interval;
};
/* commonly used functions in the separated files */
Hi Andrew,
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> fuse-transfer-readdir-data-through-device.patch
> fuse: transfer readdir data through device
It is great that this is fixed, don't remove it, but it does require the fuse
libs to be updated at the same time, or opening dirs for listings will break
like this:
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
not implemented)
As I personally like for my ls to keep on working, and I assume others will,
too, I would appreciate it if you could add a warning to your announcements the
following one or two weeks or so, so that people can remove this patch if they
don't want to update their libs.
Thank you.
Sytse
On Mon, Jan 24, 2005 at 11:26:03PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 24, 2005 at 09:36:24PM +0100, Karsten Keil wrote:
> > > - conversion to proper pci API
> >
> > ??? the driver is not PCI related at all
>
> Sorry, this was actually a comment for i4l-hfc-4s-and-hfc-8s-driver.patch.
>
OK, in the meantime I assumed this too and informed the author about the
problems, I think most things will be solved soon.
I can correct CodingStyle for hfc_usb.c too, this give ~30K bigger patch.
Thanks for the formal code checks, I forget them sometimes, if I get code
from 3 party.
--
Karsten Keil
SuSE Labs
ISDN development
Andrew Morton a ?crit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>
>
> - Lots of updates and fixes all over the place.
>
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
>
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Hi Andrew,
ACPI does not work anymore on my Compaq Evo N600c
(no thermal zone, no fan, no battery, ...).
It works great on Linus' 2.6.11-rc2, and (from what I remember)
it was working on the last -mm releases I tried.
Here's a bunch of lines from dmesg.
.config and lspci attached.
Regards,
Brice
exresnte-0133 [24] ex_resolve_node_to_val: No object attached to node e7fcd548
dswexec-0446 [21] ds_exec_end_op : [Acquire]: Could not resolve operands, AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C12A] (Node c15e5788), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_SB_.C1A2._PSR] (Node c15ed8c8), AE_AML_NO_OPERAND
acpi_ac-0098 [12] acpi_ac_get_state : Error reading AC Adapter state
ACPI: Battery Slot [C19F] (battery absent)
ACPI: Battery Slot [C1A0] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [C1A3]
ACPI: Lid Switch [C1A4]
ACPI: Fan [C1F6] (off)
ACPI: Fan [C1F7] (off)
ACPI: Fan [C1F8] (off)
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
exresnte-0133 [31] ex_resolve_node_to_val: No object attached to node e7fcd548
dswexec-0446 [28] ds_exec_end_op : [Acquire]: Could not resolve operands, AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C11A] (Node c15e5b48), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_TZ_.C11A] (Node c15ef3c8), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_TZ_.C1F1] (Node c15ef0c8), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_TZ_.TZ1_._TMP] (Node c15f05c8), AE_AML_NO_OPERAND
ACPI wakeup devices:
C052 C17E C185 C0A4 C0AA C19F C1A0 C1A3 C1A4
ACPI: (supports S0 S1 S3 S4 S4bios S5)
exresnte-0133 [26] ex_resolve_node_to_val: No object attached to node e7fcd548
dswexec-0446 [23] ds_exec_end_op : [Acquire]: Could not resolve operands, AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C119] (Node c15e5b88), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_GPE._L10] (Node c15f0248), AE_AML_NO_OPERAND
evgpe-0552: *** Error: AE_AML_NO_OPERAND while evaluating method [_L10] for GPE[ 0]
On Mon, 2005-01-24 at 20:01, Brice Goglin wrote:
> Andrew Morton a ?crit :
>
> ACPI does not work anymore on my Compaq Evo N600c
> (no thermal zone, no fan, no battery, ...).
> It works great on Linus' 2.6.11-rc2, and (from what I remember)
> it was working on the last -mm releases I tried.
>
> Here's a bunch of lines from dmesg.
...
>
>
> exresnte-0133 [24] ex_resolve_node_to_val: No object attached to node
> e7fcd548
> dswexec-0446 [21] ds_exec_end_op : [Acquire]: Could not
> resolve operands, AE_AML_NO_OPERAND
> psparse-1138: *** Error: Method execution failed
> [\_SB_.C03E.C053.C0D1.C12A] (Node c15e5788), AE_AML_NO_OPERAND
> psparse-1138: *** Error: Method execution failed [\_SB_.C1A2._PSR]
> (Node c15ed8c8), AE_AML_NO_OPERAND
> acpi_ac-0098 [12] acpi_ac_get_state : Error reading AC Adapter
> state
> ACPI: Battery Slot [C19F] (battery absent)
> ACPI: Battery Slot [C1A0] (battery absent)
> ACPI: Power Button (FF) [PWRF]
> ACPI: Sleep Button (CM) [C1A3]
> ACPI: Lid Switch [C1A4]
> ACPI: Fan [C1F6] (off)
> ACPI: Fan [C1F7] (off)
> ACPI: Fan [C1F8] (off)
> ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
> exresnte-0133 [31] ex_resolve_node_to_val: No object attached to node
> e7fcd548
> dswexec-0446 [28] ds_exec_end_op : [Acquire]: Could not
> resolve operands, AE_AML_NO_OPERAND
> psparse-1138: *** Error: Method execution failed
> [\_SB_.C03E.C053.C0D1.C11A] (Node c15e5b48), AE_AML_NO_OPERAND
> psparse-1138: *** Error: Method execution failed [\_TZ_.C11A] (Node
> c15ef3c8), AE_AML_NO_OPERAND
> psparse-1138: *** Error: Method execution failed [\_TZ_.C1F1] (Node
> c15ef0c8), AE_AML_NO_OPERAND
> psparse-1138: *** Error: Method execution failed [\_TZ_.TZ1_._TMP]
> (Node c15f05c8), AE_AML_NO_OPERAND
> ACPI wakeup devices:
> C052 C17E C185 C0A4 C0AA C19F C1A0 C1A3 C1A4
> ACPI: (supports S0 S1 S3 S4 S4bios S5)
> exresnte-0133 [26] ex_resolve_node_to_val: No object attached to node
> e7fcd548
> dswexec-0446 [23] ds_exec_end_op : [Acquire]: Could not
> resolve operands, AE_AML_NO_OPERAND
> psparse-1138: *** Error: Method execution failed
> [\_SB_.C03E.C053.C0D1.C119] (Node c15e5b88), AE_AML_NO_OPERAND
> psparse-1138: *** Error: Method execution failed [\_GPE._L10] (Node
> c15f0248), AE_AML_NO_OPERAND
> evgpe-0552: *** Error: AE_AML_NO_OPERAND while evaluating method
> [_L10] for GPE[ 0]
Please patch -Rp1 this file:
http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/bk-acpi.patch
to verify that the issue goes away when backing out the ACPI part of the
latest mm patch.
We'll likely need your acpidmp output to bottom out on this.
Please open a bug here:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Category: AML-interpreter
and attach (don't paste) the output from acpidmp, available in /usr/sbin
or in pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
along with the complete dmesg -s64000 output of the failure case.
thanks,
-Len
On Mon, Jan 24, 2005 at 09:47:51PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 24, 2005 at 01:34:42PM -0800, Greg KH wrote:
> > And as for the "these patches have never been reviewed" comments, that's
> > why I put them in my tree, and have them show up in -mm. It's getting
> > them a wider exposure and finding out these kinds of issues. So the
> > process is working properly :)
>
> It would be a lot more productive to follow the normal rules, though.
> That is posting them on lkml as properly split up patches, and with
> proper descriptions of what they're doing.
As previously mentioned, these patches have had that, on the sensors
mailing list. Lots of review and comments went into them there, and the
code was reworked quite a lot based on it.
Surely you don't want me to forward _every_ driver patch that I get to
lkml first? :)
That's what all of the subsystem specific mailing lists are for...
thanks,
greg k-h
On Mon, Jan 24, 2005 at 10:26:09PM +0200, Michael S. Tsirkin wrote:
> Hi!
> The new ioctl code in fs/compat.c can be streamlined a little
> using the compat hash instead of an explicit switch statement.
>
> The attached patch is against 2.6.11-rc2-bk2.
> Andi, could you please comment? Does this make sence?
Problem is that when a compat_ioctl handler returns -EINVAL
instead of -ENOIOCTLCMD on unknown ioctl it won't check the common
ones.
I fear this mistake would be common, that is why I put in the switch.
-Andi
On Mon, Jan 24, 2005 at 05:14:04PM +0300, Evgeniy Polyakov wrote:
> Remove unneded exports and make some functions static.
>
> Signed-off-by: Evgeniy Polyakov <[email protected]>
Applied, thanks.
greg k-h
On Mon, Jan 24, 2005 at 10:02:56PM -0800, Greg KH wrote:
> > It would be a lot more productive to follow the normal rules, though.
> > That is posting them on lkml as properly split up patches, and with
> > proper descriptions of what they're doing.
>
> As previously mentioned, these patches have had that, on the sensors
> mailing list. Lots of review and comments went into them there, and the
> code was reworked quite a lot based on it.
>
> Surely you don't want me to forward _every_ driver patch that I get to
> lkml first? :)
If you add completely new subsystems please send them to lkml first.
> > fuse-transfer-readdir-data-through-device.patch
> > fuse: transfer readdir data through device
> It is great that this is fixed, don't remove it, but it does require the fuse
> libs to be updated at the same time, or opening dirs for listings will break
> like this:
>
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
> not implemented)
>
> As I personally like for my ls to keep on working, and I assume
> others will, too, I would appreciate it if you could add a warning
> to your announcements the following one or two weeks or so, so that
> people can remove this patch if they don't want to update their
> libs.
This is my fault, sorry.
I promise, that there'll be no more backward incompatible changes (and
if there will, a big warning about library dependency will be added :).
Thanks,
Miklos
> > The patch below should fix this.
>
> Not completely:
> CC drivers/media/video/saa7134/saa7134-core.o
> drivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':
> drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress' undeclared (first use in this function)
New version, this time using a #define, which should kill the reference
to need_* as well ...
Gerd
Index: linux-2005-01-23/drivers/media/video/saa7134/saa7134-core.c
===================================================================
--- linux-2005-01-23.orig/drivers/media/video/saa7134/saa7134-core.c 2005-01-24 18:43:20.000000000 +0100
+++ linux-2005-01-23/drivers/media/video/saa7134/saa7134-core.c 2005-01-25 10:04:17.000000000 +0100
@@ -21,6 +21,7 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include <linux/config.h>
#include <linux/init.h>
#include <linux/list.h>
#include <linux/module.h>
@@ -225,6 +226,8 @@ static void dump_statusregs(struct saa71
/* ----------------------------------------------------------- */
/* delayed request_module */
+#ifdef CONFIG_MODULES
+
static int need_empress;
static int need_dvb;
@@ -265,6 +268,12 @@ static void request_module_depend(char *
}
}
+#else
+
+#define request_module_depend(name,flag)
+
+#endif /* CONFIG_MODULES */
+
/* ------------------------------------------------------------------ */
/* nr of (saa7134-)pages for the given buffer size */
On Tue, Jan 25, 2005 at 11:15:09AM +0100, Gerd Knorr wrote:
> > > The patch below should fix this.
> >
> > Not completely:
>
> > CC drivers/media/video/saa7134/saa7134-core.o
> > drivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':
> > drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress' undeclared (first use in this function)
>
> New version, this time using a #define, which should kill the reference
> to need_* as well ...
I can confirm that this patch fixes the compilation.
> Gerd
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Review of the superio subsystem sneaked in through bk-i2c.patch:
diff -Nru a/drivers/superio/Kconfig b/drivers/superio/Kconfig
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/superio/Kconfig 2005-01-23 22:34:15 -08:00
@@ -0,0 +1,56 @@
+menu "SuperIO subsystem support"
+
+config SC_SUPERIO
+ tristate "SuperIO subsystem support"
+ depends on CONNECTOR
+ help
+ SuperIO subsystem support.
+
+ This support is also available as a module. If so, the module
+ will be called superio.ko.
This doesn't mention what "SuperIO" is at all. Also please skip the .ko
postfix for the module name as the intree Kconfigs do. The boilerplate has
changed to:
To compile this driver as a module, choose M here: the
module will be called <foo>.
diff -Nru a/drivers/superio/Makefile b/drivers/superio/Makefile
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/superio/Makefile 2005-01-23 22:34:15 -08:00
@@ -0,0 +1,11 @@
+#
+# Makefile for the SuperIO subsystem.
+#
Superflous.
+
+obj-$(CONFIG_SC_SUPERIO) += superio.o
+obj-$(CONFIG_SC_GPIO) += sc_gpio.o
+obj-$(CONFIG_SC_ACB) += sc_acb.o
+obj-$(CONFIG_SC_PC8736X) += pc8736x.o
+obj-$(CONFIG_SC_SCX200) += scx200.o
+
+superio-objs := sc.o chain.o sc_conn.o
please use superio-y += so new conditional objects can be added more easily.
diff -Nru a/drivers/superio/chain.c b/drivers/superio/chain.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/superio/chain.c 2005-01-23 22:34:15 -08:00
@@ -0,0 +1,52 @@
+/*
+ * chain.c
superfluos, the file name is obvious. (Dito for all other files)
+ *
+ * 2004 Copyright (c) Evgeniy Polyakov <[email protected]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <asm/atomic.h>
+#include <asm/types.h>
+
+#include <linux/list.h>
+#include <linux/slab.h>
always include <asm/*> after <linux/*> headers. Please use <linux/types.h>
istead of <asm/types.h> always.
(comment applies to later files aswell)
+#include "chain.h"
+
+struct dev_chain *chain_alloc(void *ptr)
+{
+ struct dev_chain *ch;
+
+ ch = kmalloc(sizeof(struct dev_chain), GFP_ATOMIC);
+ if (!ch) {
+ printk(KERN_ERR "Failed to allocate new chain for %p.\n", ptr);
+ return NULL;
+ }
+
+ memset(ch, 0, sizeof(struct dev_chain));
+
+ ch->ptr = ptr;
+
+ return ch;
+}
+
+void chain_free(struct dev_chain *ch)
+{
+ memset(ch, 0, sizeof(struct dev_chain));
+ kfree(ch);
The memset completely defeats slab redzoning to catch bugs, don't
do that.
Also what's the reason you can't simply put the list_head into struct
logical_dev?
+static void pc8736x_fini(void)
+{
+ sc_del_sc_dev(&pc8736x_dev);
+
+ while (atomic_read(&pc8736x_dev.refcnt)) {
+ printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
+ pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+
+ if (current->flags & PF_FREEZE)
+ refrigerator(PF_FREEZE);
+
+ if (signal_pending(current))
+ flush_signals(current);
+ }
+}
And who gurantess this won't deadlock? Please use a dynamically allocated
driver model device and it's refcounting, thanks.
+int sc_add_sc_dev(struct sc_dev *__sdev)
btw, what's the reason you use those ugly __ names for local variables all over?
+ while (atomic_read(&__sdev->refcnt)) {
+ printk(KERN_INFO "Waiting SuperIO chip %s to become free: refcnt=%d.\n",
+ __sdev->name, atomic_read(&__sdev->refcnt));
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(HZ);
+
+ if (current->flags & PF_FREEZE)
+ refrigerator(PF_FREEZE);
+
+ if (signal_pending(current))
+ flush_signals(current);
+ }
+}
Again as above.
+static void sc_deactivate_logical(struct sc_dev *dev, struct logical_dev *ldev)
+{
+ printk(KERN_INFO "Deactivating logical device %s in SuperIO chip %s... ",
+ ldev->name, dev->name);
+
+ if (ldev->irq)
+ {
+ free_irq(ldev->irq, ldev);
+ ldev->irq = 0;
+ }
CodingStyle: if (ldev->irq) { (also in various other places)
+static int __devinit sc_init(void)
+{
+ printk(KERN_INFO "SuperIO driver is starting...\n");
+
+ return sc_register_callback();
+}
+
+static void __devexit sc_fini(void)
+{
+ sc_unregister_callback();
+ printk(KERN_INFO "SuperIO driver finished.\n");
+}
quite noise. Please only print messages when you find an actual
device and not on unloading at all.
+ INIT_LIST_HEAD(&ldev_acb.ldev_entry);
+ spin_lock_init(&ldev_acb.lock);
these two can be initialized at compile time.
+#include "../superio/sc.h"
+#include "../superio/sc_gpio.h"
just include them normalluy, ok?
+static int scx200_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ private_base = pci_resource_start(pdev, 0);
+ printk(KERN_INFO "%s: GPIO base 0x%lx.\n", pci_name(pdev), private_base);
+
+ if (!request_region
+ (private_base, SCx200_GPIO_SIZE, "NatSemi SCx200 GPIO")) {
+ printk(KERN_ERR "%s: failed to request %d bytes I/O region for GPIOs.\n",
+ pci_name(pdev), SCx200_GPIO_SIZE);
+ return -EBUSY;
+ }
+
+ pci_set_drvdata(pdev, &private_base);
+ pci_enable_device(pdev);
pci_enable_device needs to be done first, and it returns and error that
should be handled.
+ pci_unregister_driver(&scx200_pci_driver);
+ if (private_base)
+ release_region(private_base, SCx200_GPIO_SIZE);
this must happen in the ->remove callback.
diff -Nru a/drivers/superio/scx200.h b/drivers/superio/scx200.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/superio/scx200.h 2005-01-23 22:34:15 -08:00
@@ -0,0 +1,28 @@
+/*
+ * scx200.h
+ *
+ * 2004 Copyright (c) Evgeniy Polyakov <[email protected]>
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef __SCX200_H
+#define __SCX200_H
+
+#define SCx200_GPIO_SIZE 0x2c
+
+#endif /* __SCX200_H */
Yeah, right - a 30 line header for a single define that's used in a
single source file..
Also your locking is broken. sdev_lock sometimes nests outside
sdev->lock and sometimes inside. Similarly dev->chain_lock nests
inside dev->lock sometimes and sometimes outside. You really need
a locking hiearchy document and the lockign should probably be
simplified a lot.
On Tue, 2005-01-25 at 12:53 +0000, Christoph Hellwig wrote:
> Review of the superio subsystem sneaked in through bk-i2c.patch:
Hmm, "sneaked"... Good start, Christoph.
> diff -Nru a/drivers/superio/Kconfig b/drivers/superio/Kconfig
> --- /dev/null Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/Kconfig 2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,56 @@
> +menu "SuperIO subsystem support"
> +
> +config SC_SUPERIO
> + tristate "SuperIO subsystem support"
> + depends on CONNECTOR
> + help
> + SuperIO subsystem support.
> +
> + This support is also available as a module. If so, the module
> + will be called superio.ko.
>
> This doesn't mention what "SuperIO" is at all. Also please skip the .ko
> postfix for the module name as the intree Kconfigs do. The boilerplate has
> changed to:
Ok.
> To compile this driver as a module, choose M here: the
> module will be called <foo>.
>
> diff -Nru a/drivers/superio/Makefile b/drivers/superio/Makefile
> --- /dev/null Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/Makefile 2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,11 @@
> +#
> +# Makefile for the SuperIO subsystem.
> +#
>
> Superflous.
>
> +
> +obj-$(CONFIG_SC_SUPERIO) += superio.o
> +obj-$(CONFIG_SC_GPIO) += sc_gpio.o
> +obj-$(CONFIG_SC_ACB) += sc_acb.o
> +obj-$(CONFIG_SC_PC8736X) += pc8736x.o
> +obj-$(CONFIG_SC_SCX200) += scx200.o
> +
> +superio-objs := sc.o chain.o sc_conn.o
>
> please use superio-y += so new conditional objects can be added more easily.
They must be added in the same file and line to allow easy control.
It is not directory like char/.
> diff -Nru a/drivers/superio/chain.c b/drivers/superio/chain.c
> --- /dev/null Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/chain.c 2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,52 @@
> +/*
> + * chain.c
>
> superfluos, the file name is obvious. (Dito for all other files)
>
> + *
> + * 2004 Copyright (c) Evgeniy Polyakov <[email protected]>
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + */
> +
> +#include <asm/atomic.h>
> +#include <asm/types.h>
> +
> +#include <linux/list.h>
> +#include <linux/slab.h>
>
> always include <asm/*> after <linux/*> headers. Please use <linux/types.h>
> istead of <asm/types.h> always.
>
> (comment applies to later files aswell)
Ok.
> +#include "chain.h"
> +
> +struct dev_chain *chain_alloc(void *ptr)
> +{
> + struct dev_chain *ch;
> +
> + ch = kmalloc(sizeof(struct dev_chain), GFP_ATOMIC);
> + if (!ch) {
> + printk(KERN_ERR "Failed to allocate new chain for %p.\n", ptr);
> + return NULL;
> + }
> +
> + memset(ch, 0, sizeof(struct dev_chain));
> +
> + ch->ptr = ptr;
> +
> + return ch;
> +}
> +
> +void chain_free(struct dev_chain *ch)
> +{
> + memset(ch, 0, sizeof(struct dev_chain));
> + kfree(ch);
>
> The memset completely defeats slab redzoning to catch bugs, don't
> do that.
What? Does following code also kills redzoning?
int *a;
a = kmalloc();
if (a)
{
memset(a, 0, sizeof(*a));
kfree(a);
}
Consider size of the dev_chain structure...
> Also what's the reason you can't simply put the list_head into struct
> logical_dev?
Because it is not just list_head, but special structure used for special
pointer manipulations,
which you are obviously saw in sc.c
> +static void pc8736x_fini(void)
> +{
> + sc_del_sc_dev(&pc8736x_dev);
> +
> + while (atomic_read(&pc8736x_dev.refcnt)) {
> + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> +
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(HZ);
> +
> + if (current->flags & PF_FREEZE)
> + refrigerator(PF_FREEZE);
> +
> + if (signal_pending(current))
> + flush_signals(current);
> + }
> +}
>
> And who gurantess this won't deadlock? Please use a dynamically allocated
> driver model device and it's refcounting, thanks.
Sigh.
Christoph, please read the code before doing such comments.
I very respect your review and opinion, but only until you respect
others.
> +int sc_add_sc_dev(struct sc_dev *__sdev)
>
> btw, what's the reason you use those ugly __ names for local variables all over?
>
> + while (atomic_read(&__sdev->refcnt)) {
> + printk(KERN_INFO "Waiting SuperIO chip %s to become free: refcnt=%d.\n",
> + __sdev->name, atomic_read(&__sdev->refcnt));
> + set_current_state(TASK_UNINTERRUPTIBLE);
> + schedule_timeout(HZ);
> +
> + if (current->flags & PF_FREEZE)
> + refrigerator(PF_FREEZE);
> +
> + if (signal_pending(current))
> + flush_signals(current);
> + }
> +}
>
> Again as above.
>
> +static void sc_deactivate_logical(struct sc_dev *dev, struct logical_dev *ldev)
> +{
> + printk(KERN_INFO "Deactivating logical device %s in SuperIO chip %s... ",
> + ldev->name, dev->name);
> +
> + if (ldev->irq)
> + {
> + free_irq(ldev->irq, ldev);
> + ldev->irq = 0;
> + }
>
> CodingStyle: if (ldev->irq) { (also in various other places)
Yep.
> +static int __devinit sc_init(void)
> +{
> + printk(KERN_INFO "SuperIO driver is starting...\n");
> +
> + return sc_register_callback();
> +}
> +
> +static void __devexit sc_fini(void)
> +{
> + sc_unregister_callback();
> + printk(KERN_INFO "SuperIO driver finished.\n");
> +}
>
> quite noise. Please only print messages when you find an actual
> device and not on unloading at all.
>
> + INIT_LIST_HEAD(&ldev_acb.ldev_entry);
> + spin_lock_init(&ldev_acb.lock);
>
> these two can be initialized at compile time.
Ok.
> +#include "../superio/sc.h"
> +#include "../superio/sc_gpio.h"
>
> just include them normalluy, ok?
Sure.
> +static int scx200_pci_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + private_base = pci_resource_start(pdev, 0);
> + printk(KERN_INFO "%s: GPIO base 0x%lx.\n", pci_name(pdev), private_base);
> +
> + if (!request_region
> + (private_base, SCx200_GPIO_SIZE, "NatSemi SCx200 GPIO")) {
> + printk(KERN_ERR "%s: failed to request %d bytes I/O region for GPIOs.\n",
> + pci_name(pdev), SCx200_GPIO_SIZE);
> + return -EBUSY;
> + }
> +
> + pci_set_drvdata(pdev, &private_base);
> + pci_enable_device(pdev);
>
> pci_enable_device needs to be done first, and it returns and error that
> should be handled.
Yep, it can be a problem, thank you.
> + pci_unregister_driver(&scx200_pci_driver);
> + if (private_base)
> + release_region(private_base, SCx200_GPIO_SIZE);
>
> this must happen in the ->remove callback.
>
> diff -Nru a/drivers/superio/scx200.h b/drivers/superio/scx200.h
> --- /dev/null Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/scx200.h 2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,28 @@
> +/*
> + * scx200.h
> + *
> + * 2004 Copyright (c) Evgeniy Polyakov <[email protected]>
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + */
> +
> +#ifndef __SCX200_H
> +#define __SCX200_H
> +
> +#define SCx200_GPIO_SIZE 0x2c
> +
> +#endif /* __SCX200_H */
>
> Yeah, right - a 30 line header for a single define that's used in a
> single source file..
Christoph, do you know what SuperIO is?
I doubt...
It is a small chip, which can include various number of devices.
SuperIO currently supports only GPIO and ACB, so this header only
includes
one define. I do not have hardware(sc1100 based for example) that
"exports"
other devices and which can be accessed from the outside of the board,
so I did not add other defines.
But specially for you I can remove this file, will it satisfy you?
> Also your locking is broken. sdev_lock sometimes nests outside
> sdev->lock and sometimes inside. Similarly dev->chain_lock nests
> inside dev->lock sometimes and sometimes outside. You really need
> a locking hiearchy document and the lockign should probably be
> simplified a lot.
It is almost the same like after hand waving say that there is a wind.
Each lock protect it's own data, sometimes it happens when other data is
locked,
sometimes not. Yes, probably interrupt handling can race, it requires
more review,
I will take a look.
Below is part of the announce in lm_sensors@ which probably will throw
light on your
claims.
************
Main goal was to be able to link any registered SuperIO chip with any
number of registered logical devices. Next step is to add ability to
communicate with SuperIO subsystem from userspace.
External kernel modules may access to logical devices using
sc_{get,put}_ldev() and in similar way to SuperIO chip drivers -
sc_{get,put}_sdev().
Driver writers shoud use sc_{add,del}_logical_dev() and
sc_{add,del}_sc_dev() to accordingly add/remove logical devices and
SuperIO chip drivers.
Any SuperIO chip driver must provite at least 2 functions:
->probe() and ->activate_one().
The former is called with different HW addresses and should return 0 if
device was found there or negative error value.
The latter is called each time new logical device being added with
pointer to it's logical device structure. It should return 0 if logical
device was found to be active or negative error value.
Any logical device must provide 4 functions:
->activate() - it is used to activate logical device.
->read()/write() - what do you think, it is used to read and write
from/to logical device registers.
->control() - it is used to control access to logical device. Actually
it is private combination of ->read()/write() functions but is providede
for convenience.
********************
Resume:
Cristoph, you rudely try to show that this code is badly broken.
It is not.
It was tested as opposed to your claims, and works as expected.
To be more productive please next time be polite and respect others,
or you will be just ignored no matter how strong your knowledges are.
Talk is cheap, show me the code, that is broken, and I will fix it.
Thank you.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
> > +obj-$(CONFIG_SC_SUPERIO) += superio.o
> > +obj-$(CONFIG_SC_GPIO) += sc_gpio.o
> > +obj-$(CONFIG_SC_ACB) += sc_acb.o
> > +obj-$(CONFIG_SC_PC8736X) += pc8736x.o
> > +obj-$(CONFIG_SC_SCX200) += scx200.o
> > +
> > +superio-objs := sc.o chain.o sc_conn.o
> >
> > please use superio-y += so new conditional objects can be added more easily.
>
> They must be added in the same file and line to allow easy control.
> It is not directory like char/.
Huh?
What I mean is you should write
superio-y += sc.o chain.o sc_conn.o
this allows adding things like
superio-$(CONFIG_FOO) += sc_foo.o
and is generally the canonical form since 2.6
> > +void chain_free(struct dev_chain *ch)
> > +{
> > + memset(ch, 0, sizeof(struct dev_chain));
> > + kfree(ch);
> >
> > The memset completely defeats slab redzoning to catch bugs, don't
> > do that.
>
> What? Does following code also kills redzoning?
>
> int *a;
> a = kmalloc();
> if (a)
> {
> memset(a, 0, sizeof(*a));
> kfree(a);
> }
>
> Consider size of the dev_chain structure...
Sorry, didn't mean redzoning but poisoning in general, little
brainfart on my side. The slab code can set freed objects to
known patters so use after frees can be debugged easily, and
by zeroing a structure before freeing we lose that.
> > Also what's the reason you can't simply put the list_head into struct
> > logical_dev?
>
> Because it is not just list_head, but special structure used for special
> pointer manipulations,
> which you are obviously saw in sc.c
No, I didn't see it. I see that the void pointer ptr in struct dev_chain
always points to a struct sc_dev *, and I see we never change that
pointer at run time. I might have missed something obvious, so maybe
you could point me to it (or even better add a comment describing it)
>
> > +static void pc8736x_fini(void)
> > +{
> > + sc_del_sc_dev(&pc8736x_dev);
> > +
> > + while (atomic_read(&pc8736x_dev.refcnt)) {
> > + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > +
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule_timeout(HZ);
> > +
> > + if (current->flags & PF_FREEZE)
> > + refrigerator(PF_FREEZE);
> > +
> > + if (signal_pending(current))
> > + flush_signals(current);
> > + }
> > +}
> >
> > And who gurantess this won't deadlock? Please use a dynamically allocated
> > driver model device and it's refcounting, thanks.
>
> Sigh.
>
> Christoph, please read the code before doing such comments.
> I very respect your review and opinion, but only until you respect
> others.
The code above pretty much means you can keep rmmod stalled forever.
Also it seems to be the only code intree doing refrigerator() on anything
but kernel thread. While I can't comment on swsusp internals it surely
looks buggy to me.
> > +#ifndef __SCX200_H
> > +#define __SCX200_H
> > +
> > +#define SCx200_GPIO_SIZE 0x2c
> > +
> > +#endif /* __SCX200_H */
> >
> > Yeah, right - a 30 line header for a single define that's used in a
> > single source file..
>
> Christoph, do you know what SuperIO is?
> I doubt...
>
> It is a small chip, which can include various number of devices.
> SuperIO currently supports only GPIO and ACB, so this header only
> includes
> one define. I do not have hardware(sc1100 based for example) that
> "exports"
> other devices and which can be accessed from the outside of the board,
> so I did not add other defines.
>
> But specially for you I can remove this file, will it satisfy you?
I've just told you it looks extremly silly, you need to decide on your
own whether it's worthwile.
> > Also your locking is broken. sdev_lock sometimes nests outside
> > sdev->lock and sometimes inside. Similarly dev->chain_lock nests
> > inside dev->lock sometimes and sometimes outside. You really need
> > a locking hiearchy document and the lockign should probably be
> > simplified a lot.
>
> It is almost the same like after hand waving say that there is a wind.
>
> Each lock protect it's own data, sometimes it happens when other data is
> locked,
> sometimes not. Yes, probably interrupt handling can race, it requires
> more review,
> I will take a look.
The thing I mention is called lock order reversal, which means a deadlock
in most cases. I don't have the time to actual walk through all codepathes
to tell you whether it can really happen and where, but it's a really
big warning sign.
> Resume:
> Cristoph, you rudely try to show that this code is badly broken.
> It is not.
> It was tested as opposed to your claims, and works as expected.
I've seen tons of code that "works as expected" but still is buggy.
That's why code needs to be both tested (with a workload as
expected and other stress testing that shows it handles loads _not_
expected) and reviewed for errors that don't happen with a normal
load or design problems.
On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > +obj-$(CONFIG_SC_SUPERIO) += superio.o
> > > +obj-$(CONFIG_SC_GPIO) += sc_gpio.o
> > > +obj-$(CONFIG_SC_ACB) += sc_acb.o
> > > +obj-$(CONFIG_SC_PC8736X) += pc8736x.o
> > > +obj-$(CONFIG_SC_SCX200) += scx200.o
> > > +
> > > +superio-objs := sc.o chain.o sc_conn.o
> > >
> > > please use superio-y += so new conditional objects can be added more easily.
> >
> > They must be added in the same file and line to allow easy control.
> > It is not directory like char/.
>
> Huh?
>
> What I mean is you should write
>
> superio-y += sc.o chain.o sc_conn.o
>
> this allows adding things like
>
> superio-$(CONFIG_FOO) += sc_foo.o
>
> and is generally the canonical form since 2.6
Yes, I understand you, but this is the case when it is not supposed to
have external dependent features, they are already inside :)
But who knows.
I think it is better to change.
> > > +void chain_free(struct dev_chain *ch)
> > > +{
> > > + memset(ch, 0, sizeof(struct dev_chain));
> > > + kfree(ch);
> > >
> > > The memset completely defeats slab redzoning to catch bugs, don't
> > > do that.
> >
> > What? Does following code also kills redzoning?
> >
> > int *a;
> > a = kmalloc();
> > if (a)
> > {
> > memset(a, 0, sizeof(*a));
> > kfree(a);
> > }
> >
> > Consider size of the dev_chain structure...
>
> Sorry, didn't mean redzoning but poisoning in general, little
> brainfart on my side. The slab code can set freed objects to
> known patters so use after frees can be debugged easily, and
> by zeroing a structure before freeing we lose that.
Zeroing can be found easily - the whole structure is NULL pointer,
and will always panic if accessed(from running superio code),
but redzoning is only happen on borders,
and can catch writes over the boards, which is rarely in this case.
> > > Also what's the reason you can't simply put the list_head into struct
> > > logical_dev?
> >
> > Because it is not just list_head, but special structure used for special
> > pointer manipulations,
> > which you are obviously saw in sc.c
>
> No, I didn't see it. I see that the void pointer ptr in struct dev_chain
> always points to a struct sc_dev *, and I see we never change that
> pointer at run time. I might have missed something obvious, so maybe
> you could point me to it (or even better add a comment describing it)
Each superio chip is registered with superio core without any devices.
Each logical device is registered with superio core without any superio
chip.
Then core checks if some chip is found in some superio device, and
links
it to appropriate device.
So if board has several superio chips(like soekris board) and several
logical devices in it, then we only have 2 superio small drivers, and
several
logical device drivers, but not
number_of_superio_chips*number_of_logical_devices drivers.
Without dev_chain structure each logical device should have a separate
list of
superio chips that owns it.
Above chain structure is a glue between superio core, logical devices
and superio chips.
It is especially usefull in case of logical device cloning, when chip
does not follow
the standart and place it somewhere else, but to allow access to it
superio core
"clones" logical device and link them instead of the standart one.
> >
> > > +static void pc8736x_fini(void)
> > > +{
> > > + sc_del_sc_dev(&pc8736x_dev);
> > > +
> > > + while (atomic_read(&pc8736x_dev.refcnt)) {
> > > + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > > + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > > +
> > > + set_current_state(TASK_INTERRUPTIBLE);
> > > + schedule_timeout(HZ);
> > > +
> > > + if (current->flags & PF_FREEZE)
> > > + refrigerator(PF_FREEZE);
> > > +
> > > + if (signal_pending(current))
> > > + flush_signals(current);
> > > + }
> > > +}
> > >
> > > And who gurantess this won't deadlock? Please use a dynamically allocated
> > > driver model device and it's refcounting, thanks.
> >
> > Sigh.
> >
> > Christoph, please read the code before doing such comments.
> > I very respect your review and opinion, but only until you respect
> > others.
>
> The code above pretty much means you can keep rmmod stalled forever.
Yes, and it is better than removing module whose structures are in use.
SuperIO core is asynchronous in it's nature, one can use logical device
through superio core and remove it's module on other CPU, above loop
will
wait untill all reference counters are dropped.
Access to devices can be done not through ioctl or such mechanism which
"locks" the module owner.
It is better than module_get() since with the latter variant we may end
up
not removing device at all.
> Also it seems to be the only code intree doing refrigerator() on anything
> but kernel thread. While I can't comment on swsusp internals it surely
> looks buggy to me.
>
> > > +#ifndef __SCX200_H
> > > +#define __SCX200_H
> > > +
> > > +#define SCx200_GPIO_SIZE 0x2c
> > > +
> > > +#endif /* __SCX200_H */
> > >
> > > Yeah, right - a 30 line header for a single define that's used in a
> > > single source file..
> >
> > Christoph, do you know what SuperIO is?
> > I doubt...
> >
> > It is a small chip, which can include various number of devices.
> > SuperIO currently supports only GPIO and ACB, so this header only
> > includes
> > one define. I do not have hardware(sc1100 based for example) that
> > "exports"
> > other devices and which can be accessed from the outside of the board,
> > so I did not add other defines.
> >
> > But specially for you I can remove this file, will it satisfy you?
>
> I've just told you it looks extremly silly, you need to decide on your
> own whether it's worthwile.
>
> > > Also your locking is broken. sdev_lock sometimes nests outside
> > > sdev->lock and sometimes inside. Similarly dev->chain_lock nests
> > > inside dev->lock sometimes and sometimes outside. You really need
> > > a locking hiearchy document and the lockign should probably be
> > > simplified a lot.
> >
> > It is almost the same like after hand waving say that there is a wind.
> >
> > Each lock protect it's own data, sometimes it happens when other data is
> > locked,
> > sometimes not. Yes, probably interrupt handling can race, it requires
> > more review,
> > I will take a look.
>
> The thing I mention is called lock order reversal, which means a deadlock
> in most cases. I don't have the time to actual walk through all codepathes
> to tell you whether it can really happen and where, but it's a really
> big warning sign.
No, it is not called lock order reversal.
There are no places like
lock a
lock b
unlock a
unlock b
and if they are, then I'm completely wrong.
What you see is only following:
place 1:
lock a
lock b
unlock b
lock c
unlock c
unlock a
place 2:
lock b
lock a
unlock a
lock c
unlock c
unlock b
It is done since manipulation with the chain pointer can be done from
logical device structure and from superio chip structure, and this
operations are absolutely the same in nature.
> > Resume:
> > Cristoph, you rudely try to show that this code is badly broken.
> > It is not.
> > It was tested as opposed to your claims, and works as expected.
>
> I've seen tons of code that "works as expected" but still is buggy.
> That's why code needs to be both tested (with a workload as
> expected and other stress testing that shows it handles loads _not_
> expected) and reviewed for errors that don't happen with a normal
> load or design problems.
Yes, you are right, of course.
That is why we write code, test and discuss(but not knock against each
other) it.
I will send patch to address your comments soon, thank you.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > > Also your locking is broken. sdev_lock sometimes nests outside
> > > > sdev->lock and sometimes inside. Similarly dev->chain_lock nests
> > > > inside dev->lock sometimes and sometimes outside. You really need
> > > > a locking hiearchy document and the lockign should probably be
> > > > simplified a lot.
> > >
> > > It is almost the same like after hand waving say that there is a wind.
> > >
> > > Each lock protect it's own data, sometimes it happens when other data is
> > > locked,
> > > sometimes not. Yes, probably interrupt handling can race, it requires
> > > more review,
> > > I will take a look.
> >
> > The thing I mention is called lock order reversal, which means a deadlock
> > in most cases. I don't have the time to actual walk through all codepathes
> > to tell you whether it can really happen and where, but it's a really
> > big warning sign.
>
> No, it is not called lock order reversal.
>
> There are no places like
> lock a
> lock b
> unlock a
> unlock b
>
> and if they are, then I'm completely wrong.
>
> What you see is only following:
>
> place 1:
> lock a
> lock b
> unlock b
> lock c
> unlock c
> unlock a
>
> place 2:
> lock b
> lock a
> unlock a
> lock c
> unlock c
> unlock b
Ugh, now think about that:
CPU0 CPU1
place1: place2:
lock a lock b
< guess what happens here :-) >
lock b lock a
... ...
Evgeniy Polyakov wrote:
> [...]
> No, it is not called lock order reversal.
>
> There are no places like
> lock a
> lock b
> unlock a
> unlock b
This would be perfectly fine. The order of unlocking doesn't really
matter. It is the actual locking that must be carried out on the same
order everywhere to guarantee that there are no deadlocks.
> and if they are, then I'm completely wrong.
>
> What you see is only following:
>
> place 1:
> lock a
> lock b
> unlock b
> lock c
> unlock c
> unlock a
>
> place 2:
> lock b
> lock a
> unlock a
> lock c
> unlock c
> unlock b
I haven't look at the code yet, but this is a deadlock waiting to
happen. "place 1" gets "lock a", then is interrupted and "place 2" gets
"lock b". "place 2" waits forever for "lock a" and "place 1" waits
forever for "lock b". Deadlock.
--
Paulo Marques - http://www.grupopie.com
"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu
On Tue, 2005-01-25 at 16:34 +0100, Bartlomiej Zolnierkiewicz wrote:
> > There are no places like
> > lock a
> > lock b
> > unlock a
> > unlock b
> >
> > and if they are, then I'm completely wrong.
> >
> > What you see is only following:
> >
> > place 1:
> > lock a
> > lock b
> > unlock b
> > lock c
> > unlock c
> > unlock a
> >
> > place 2:
> > lock b
> > lock a
> > unlock a
> > lock c
> > unlock c
> > unlock b
>
> Ugh, now think about that:
>
> CPU0 CPU1
> place1: place2:
> lock a lock b
> < guess what happens here :-) >
> lock b lock a
> ... ...
:) he-he, such place are in add and remove routings, and they can not be
run simultaneously
in different CPUs.
And in other places they should go through the same lock(sdev or chain):
like
lock sdev_lock
lock chain
unclok chain
lock logic
unlock logic
unlock sdev_lock
lock sdev_lock
lock logic
unlock logic
lock chain
unclok chain
unlock sdev_lock
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > > +static void pc8736x_fini(void)
> > > > +{
> > > > + sc_del_sc_dev(&pc8736x_dev);
> > > > +
> > > > + while (atomic_read(&pc8736x_dev.refcnt)) {
> > > > + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > > > + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > > > +
> > > > + set_current_state(TASK_INTERRUPTIBLE);
> > > > + schedule_timeout(HZ);
> > > > +
> > > > + if (current->flags & PF_FREEZE)
> > > > + refrigerator(PF_FREEZE);
> > > > +
> > > > + if (signal_pending(current))
> > > > + flush_signals(current);
> > > > + }
> > > > +}
> > > >
> > > > And who gurantess this won't deadlock? Please use a dynamically allocated
> > > > driver model device and it's refcounting, thanks.
> > >
> > > Sigh.
> > >
> > > Christoph, please read the code before doing such comments.
> > > I very respect your review and opinion, but only until you respect
> > > others.
> >
> > The code above pretty much means you can keep rmmod stalled forever.
>
> Yes, and it is better than removing module whose structures are in use.
> SuperIO core is asynchronous in it's nature, one can use logical device
> through superio core and remove it's module on other CPU, above loop
> will wait untill all reference counters are dropped.
I have a slightly different concern - the superio is a completely new
subsystem and it should be integtrated with the driver model
("superio" bus?). Right now it looks like it is reimplementing most of
the abstractions (device lists, driver lists, matching, probing).
Moving to driver model significatntly affects lifetime rules for the
objects, etc. etc. and will definitely not allow code such as above.
It would be nice it we get things right from the start.
--
Dmitry
On Tue, 25 January 2005 19:04:47 +0300, Evgeniy Polyakov wrote:
> On Tue, 2005-01-25 at 16:34 +0100, Bartlomiej Zolnierkiewicz wrote:
>
> > Ugh, now think about that:
> >
> > CPU0 CPU1
> > place1: place2:
> > lock a lock b
> > < guess what happens here :-) >
> > lock b lock a
> > ... ...
>
> :) he-he, such place are in add and remove routings, and they can not be
> run simultaneously
> in different CPUs.
Makes my toenails curl. Something fun I might write someday is a
statical (dead-)lock checker. The design is very simple:
o Annotate code with the lock that could be taken.
o Whenever getting a lock B, write down something like "A->B" for
every lock A we already have.
o Create a graph from the locking hierarchy obtained above.
o Look for cycles.
A cycle-free graph means that the code is deadlock-free. In the
above, the graph surely has cycles. You could argue that the checker
should be smarter, but then again - why should it? Is there a
compelling reason why locking schemes as outlined above actually make
the code better?
J?rn
--
It does not matter how slowly you go, so long as you do not stop.
-- Confucius
Hi!
> Andrew Morton a ?crit :
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> >
> >
> >- Lots of updates and fixes all over the place.
> >
> >- On my test box there is no flashing cursor on the vga console. Known
> >bug,
> > please don't report it.
> >
> > Binary searching shows that the bug was introduced by
> > cleanup-vc-array-access.patch but that patch is, unfortunately,
> > huge.
Heh, on my system, I get no cursor, and no letters, either (this is
vga text console). I *can* see the backgrounds, for example if I run
aumix I see colored blocks... Framebuffer does not seem to work,
either.
Letters are present for a while during boot; not sure what makes them
go away.
> ACPI does not work anymore on my Compaq Evo N600c
> (no thermal zone, no fan, no battery, ...).
> It works great on Linus' 2.6.11-rc2, and (from what I remember)
> it was working on the last -mm releases I tried.
I'd test on N620c, but it is rather hard without video :-(.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi all,
> As previously mentioned, these patches have had that, on the sensors
> mailing list. Lots of review and comments went into them there, and
> the code was reworked quite a lot based on it.
That's right, I did actually review Evgeniy's code some times ago, as
can be seen here:
http://archives.andrew.net.au/lm-sensors/msg27817.html
I might however add the following:
1* This was 5 months ago. I'd expect Evgeniy's code to have
significantly evolved since, so an additional review now would certainly
be welcome.
2* I only reviewed the superio code. The acb part is completely new so I
obviously couldn't comment on it back then, and I skipped the gpio part
because I admittedly have no particular interest in this part.
3* Some of my objections have been ignored by Evgeniy. Among others, the
choice of "sc" as a prefix for the superio stuff is definitely poor and
has to be changed.
http://archives.andrew.net.au/lm-sensors/msg27847.html
I don't think that getting the whole stuff (superio, acb and gpio)
merged at once is a good idea. Preferably we would merge superio alone
first, then update the drivers that are already in the kernel and could
make use of it (it87, w83627hf, pc87360 and smsc47m1, all of i2c/sensors
fame, come to mind). This would help ensure that Evgeniy's interface
choices were correct, and would additionally be a very good example of
how this interface must be used. Then, and only then IMVHO, should the
gpio and acb stuff be merged.
Before all this happens, I really would like Evgeniy to present an
overall plan of his current superio implementation. Last time we
discussed about this, we obviously had different views on the interface
level that should be proposed by the superio core, as well as how
chip-specific values should be handled (or, according to me, mostly not
handled).
Please note that I am certainly not the most qualified of us all to
review this code. What I can do is check whether I will be able to use
the new superio interface in the sensor chip drivers I mentioned above,
and that's about it. I am not familiar enough with kernel core
architectures to decide whether Evgeniy's approach is correct or not. I
am willing to help, but I can do so only within my own current skills.
Thanks,
--
Jean Delvare
http://khali.linux-fr.org/
On Tue, 25 Jan 2005 19:41:39 +0100, Pavel Machek <[email protected]> wrote:
> Heh, on my system, I get no cursor, and no letters, either (this is
> vga text console). I *can* see the backgrounds, for example if I run
> aumix I see colored blocks... Framebuffer does not seem to work,
> either.
>
> Letters are present for a while during boot; not sure what makes them
> go away.
I get the same thing, text disappairs after a second or something like
that. Framebuffer has no effect.
--
Mvh / Best regards
Espen Fjellv?r Olsen
[email protected]
Norway
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 24 Jan 2005, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
This acpi_power_off issue ( http://lkml.org/lkml/2005/1/11/88 ) still happens.
Marcos Marado
- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFB9po4mNlq8m+oD34RAuoFAKDWkLvIwIdpf/6NBQWdtML41LLXcQCcDSWq
yiRWlDpUaJrfrZR4iMKHcGY=
=nv2D
-----END PGP SIGNATURE-----
On Mon, Jan 24, 2005 at 10:31:53PM +0100, Brice Goglin wrote:
> Dave Jones a ?crit :
> >Here's the most obvious bug fixed. There still seems to be
> >something wrong however. It only successfully boots 50% of the
> >time for me, (it reboots when starting X otherwise), and when
> >it does boot, I get a flood of ...
> >Warning: kfree_skb on hard IRQ cf7b5800
> >Warning: kfree_skb on hard IRQ cf7b5800
> >Warning: kfree_skb on hard IRQ cf7b5800
> >
> >I think there may be some stupid memory corruptor bug in there still.
>
> Thanks, your patch makes X work again with DRI.
> Actually, it successfully booted 100% of the time here.
> I tried 6 or 7 times without seeing any problem like yours.
> Let me know if you want me to try something special.
It's quite remarkable that it works at all.
This is needed too on top of -mm1.
Dave
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/01/25 14:27:39-05:00 [email protected]
# [AGPGART] Silly thinko in reserve bit masking.
#
# Stupid inversion meant we passed '0' to userspace, and madness
# ensued resulting in very funky visuals.
#
# Signed-off-by: Dave Jones <[email protected]>
#
diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
--- a/drivers/char/agp/generic.c 2005-01-25 14:34:24 -05:00
+++ b/drivers/char/agp/generic.c 2005-01-25 14:34:24 -05:00
@@ -324,9 +324,9 @@
info->chipset = agp_bridge->type;
info->device = agp_bridge->dev;
if (check_bridge_mode(agp_bridge->dev))
- info->mode = agp_bridge->mode & AGP3_RESERVED_MASK;
+ info->mode = agp_bridge->mode & ~AGP3_RESERVED_MASK;
else
- info->mode = agp_bridge->mode & AGP2_RESERVED_MASK;
+ info->mode = agp_bridge->mode & ~AGP2_RESERVED_MASK;
info->aper_base = agp_bridge->gart_bus_addr;
info->aper_size = agp_return_size();
info->max_memory = agp_bridge->max_memory_agp;
Hi!
> Review of the superio subsystem sneaked in through bk-i2c.patch:
>
>
> diff -Nru a/drivers/superio/Kconfig b/drivers/superio/Kconfig
> --- /dev/null Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/Kconfig 2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,56 @@
> +menu "SuperIO subsystem support"
> +
> +config SC_SUPERIO
> + tristate "SuperIO subsystem support"
> + depends on CONNECTOR
> + help
> + SuperIO subsystem support.
> +
> + This support is also available as a module. If so, the module
> + will be called superio.ko.
>
> This doesn't mention what "SuperIO" is at all. Also please skip the .ko
> postfix for the module name as the intree Kconfigs do. The boilerplate has
> changed to:
>
> To compile this driver as a module, choose M here: the
> module will be called <foo>.
Could we kill this boilerplate? Just explain modules in CONFIG_MODULE
or something like that. Or making module name mandatory parameter for
tristates, or something like that...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Dave Jones a ?crit :
> This is needed too on top of -mm1.
>
> diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
> --- a/drivers/char/agp/generic.c 2005-01-25 14:34:24 -05:00
> +++ b/drivers/char/agp/generic.c 2005-01-25 14:34:24 -05:00
> @@ -324,9 +324,9 @@
> info->chipset = agp_bridge->type;
> info->device = agp_bridge->dev;
> if (check_bridge_mode(agp_bridge->dev))
> - info->mode = agp_bridge->mode & AGP3_RESERVED_MASK;
> + info->mode = agp_bridge->mode & ~AGP3_RESERVED_MASK;
> else
> - info->mode = agp_bridge->mode & AGP2_RESERVED_MASK;
> + info->mode = agp_bridge->mode & ~AGP2_RESERVED_MASK;
> info->aper_base = agp_bridge->gart_bus_addr;
> info->aper_size = agp_return_size();
> info->max_memory = agp_bridge->max_memory_agp;
>
Maybe that's not important, but on top of my -rc2-mm1, your patch looks like the
one I attached to this mail.
Regards,
Brice
On Tue, Jan 25, 2005 at 08:58:31PM +0100, Brice Goglin wrote:
> Dave Jones a ?crit :
> >This is needed too on top of -mm1.
> >
> >diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
> >--- a/drivers/char/agp/generic.c 2005-01-25 14:34:24 -05:00
> >+++ b/drivers/char/agp/generic.c 2005-01-25 14:34:24 -05:00
> >@@ -324,9 +324,9 @@
> > info->chipset = agp_bridge->type;
> > info->device = agp_bridge->dev;
> > if (check_bridge_mode(agp_bridge->dev))
> >- info->mode = agp_bridge->mode & AGP3_RESERVED_MASK;
> >+ info->mode = agp_bridge->mode & ~AGP3_RESERVED_MASK;
> > else
> >- info->mode = agp_bridge->mode & AGP2_RESERVED_MASK;
> >+ info->mode = agp_bridge->mode & ~AGP2_RESERVED_MASK;
> > info->aper_base = agp_bridge->gart_bus_addr;
> > info->aper_size = agp_return_size();
> > info->max_memory = agp_bridge->max_memory_agp;
> >
>
> Maybe that's not important, but on top of my -rc2-mm1, your patch looks
> like the one I attached to this mail.
Doh, yes. Your variant is needed with the multi-gart patches that
are in -mm. The one I posted is what I just committed to agpgart-bk
Dave
On Tue, 25 Jan 2005 15:36:57 +0000
Paulo Marques <[email protected]> wrote:
> Evgeniy Polyakov wrote:
> > [...]
> > No, it is not called lock order reversal.
> >
> > There are no places like
> > lock a
> > lock b
> > unlock a
> > unlock b
>
> This would be perfectly fine. The order of unlocking doesn't really
> matter. It is the actual locking that must be carried out on the same
> order everywhere to guarantee that there are no deadlocks.
It is bad style, and since unlocking changes the order someone
may pass wrong locking.
> > and if they are, then I'm completely wrong.
> >
> > What you see is only following:
> >
> > place 1:
> > lock a
> > lock b
> > unlock b
> > lock c
> > unlock c
> > unlock a
> >
> > place 2:
> > lock b
> > lock a
> > unlock a
> > lock c
> > unlock c
> > unlock b
>
> I haven't look at the code yet, but this is a deadlock waiting to
> happen. "place 1" gets "lock a", then is interrupted and "place 2" gets
> "lock b". "place 2" waits forever for "lock a" and "place 1" waits
> forever for "lock b". Deadlock.
As I said, that pathes are mutually exclusive - common pathes are guarded
by one lock always.
> --
> Paulo Marques - http://www.grupopie.com
>
> "A journey of a thousand miles begins with a single step."
> Lao-tzu, The Way of Lao-tzu
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Tue, 25 Jan 2005 11:11:42 -0500
Dmitry Torokhov <[email protected]> wrote:
> On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
> <[email protected]> wrote:
> > On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > > > +static void pc8736x_fini(void)
> > > > > +{
> > > > > + sc_del_sc_dev(&pc8736x_dev);
> > > > > +
> > > > > + while (atomic_read(&pc8736x_dev.refcnt)) {
> > > > > + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > > > > + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > > > > +
> > > > > + set_current_state(TASK_INTERRUPTIBLE);
> > > > > + schedule_timeout(HZ);
> > > > > +
> > > > > + if (current->flags & PF_FREEZE)
> > > > > + refrigerator(PF_FREEZE);
> > > > > +
> > > > > + if (signal_pending(current))
> > > > > + flush_signals(current);
> > > > > + }
> > > > > +}
> > > > >
> > > > > And who gurantess this won't deadlock? Please use a dynamically allocated
> > > > > driver model device and it's refcounting, thanks.
> > > >
> > > > Sigh.
> > > >
> > > > Christoph, please read the code before doing such comments.
> > > > I very respect your review and opinion, but only until you respect
> > > > others.
> > >
> > > The code above pretty much means you can keep rmmod stalled forever.
> >
> > Yes, and it is better than removing module whose structures are in use.
> > SuperIO core is asynchronous in it's nature, one can use logical device
> > through superio core and remove it's module on other CPU, above loop
> > will wait untill all reference counters are dropped.
>
> I have a slightly different concern - the superio is a completely new
> subsystem and it should be integtrated with the driver model
> ("superio" bus?). Right now it looks like it is reimplementing most of
> the abstractions (device lists, driver lists, matching, probing).
> Moving to driver model significatntly affects lifetime rules for the
> objects, etc. etc. and will definitely not allow code such as above.
>
> It would be nice it we get things right from the start.
bus model is not good here - we need bus in each logical device and
bus in each superio chip(or at least second case).
Each bus bus have some crosslinking to devices in other buses,
and each new device
must be checked in each bus and probably added to each device...
It is not like I see it.
Consider folowing example:
each device from set A belongs to each device from set B.
n <-> n, it is not the case when one bus can handle all features.
That is why I did not use driver model there.
It is specific design feature, which is proven to work.
> --
> Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Tue, 25 Jan 2005 19:21:10 +0100
J_rn Engel <[email protected]> wrote:
> On Tue, 25 January 2005 19:04:47 +0300, Evgeniy Polyakov wrote:
> > On Tue, 2005-01-25 at 16:34 +0100, Bartlomiej Zolnierkiewicz wrote:
> >
> > > Ugh, now think about that:
> > >
> > > CPU0 CPU1
> > > place1: place2:
> > > lock a lock b
> > > < guess what happens here :-) >
> > > lock b lock a
> > > ... ...
> >
> > :) he-he, such place are in add and remove routings, and they can not be
> > run simultaneously
> > in different CPUs.
>
> Makes my toenails curl. Something fun I might write someday is a
> statical (dead-)lock checker. The design is very simple:
>
> o Annotate code with the lock that could be taken.
> o Whenever getting a lock B, write down something like "A->B" for
> every lock A we already have.
> o Create a graph from the locking hierarchy obtained above.
> o Look for cycles.
>
> A cycle-free graph means that the code is deadlock-free. In the
> above, the graph surely has cycles. You could argue that the checker
> should be smarter, but then again - why should it? Is there a
> compelling reason why locking schemes as outlined above actually make
> the code better?
That will catch only simple cases - for the whole picture you need
to run graph generator from all allowed code pathes, but that
will require knowledge of the tested system, so it will not and
actually can not be absolutely generic.
> J_rn
>
> --
> It does not matter how slowly you go, so long as you do not stop.
> -- Confucius
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Tue, 25 Jan 2005 19:59:18 +0100
Jean Delvare <[email protected]> wrote:
> Hi all,
>
> > As previously mentioned, these patches have had that, on the sensors
> > mailing list. Lots of review and comments went into them there, and
> > the code was reworked quite a lot based on it.
>
> That's right, I did actually review Evgeniy's code some times ago, as
> can be seen here:
> http://archives.andrew.net.au/lm-sensors/msg27817.html
>
> I might however add the following:
>
> 1* This was 5 months ago. I'd expect Evgeniy's code to have
> significantly evolved since, so an additional review now would certainly
> be welcome.
superio core was not changed much, all related changes were posted into
lm_sensors mail list and discussed.
> 2* I only reviewed the superio code. The acb part is completely new so I
> obviously couldn't comment on it back then, and I skipped the gpio part
> because I admittedly have no particular interest in this part.
acb and gpio are logical devices and are very simple.
It was design task to create such model, where each device is as simple
as possible, and only handle low-level operations.
> 3* Some of my objections have been ignored by Evgeniy. Among others, the
> choice of "sc" as a prefix for the superio stuff is definitely poor and
> has to be changed.
>
> http://archives.andrew.net.au/lm-sensors/msg27847.html
Yep %)
SuperIO Control - is a good name, sio_ I've seen somewhere...
> I don't think that getting the whole stuff (superio, acb and gpio)
> merged at once is a good idea. Preferably we would merge superio alone
> first, then update the drivers that are already in the kernel and could
> make use of it (it87, w83627hf, pc87360 and smsc47m1, all of i2c/sensors
> fame, come to mind). This would help ensure that Evgeniy's interface
> choices were correct, and would additionally be a very good example of
> how this interface must be used. Then, and only then IMVHO, should the
> gpio and acb stuff be merged.
>
> Before all this happens, I really would like Evgeniy to present an
> overall plan of his current superio implementation. Last time we
> discussed about this, we obviously had different views on the interface
> level that should be proposed by the superio core, as well as how
> chip-specific values should be handled (or, according to me, mostly not
> handled).
GPIO and AccessBus are very simple devices, and I added them just because
1. people often asked exactly about GPIO
2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too,
but noone never asked in any mail list about them, but I think it worth
to implement.
Addind SuperIO itself does not have much sence that it can not be
tested without at least one logical device, thus I added two.
Porting existing SuperIO devices to the new schema is a very good task,
but I had only SC1100 processor and PC87366 chip, so I created and tested
superio chip drivers for them.
> Please note that I am certainly not the most qualified of us all to
> review this code. What I can do is check whether I will be able to use
> the new superio interface in the sensor chip drivers I mentioned above,
> and that's about it. I am not familiar enough with kernel core
> architectures to decide whether Evgeniy's approach is correct or not. I
> am willing to help, but I can do so only within my own current skills.
I always appreciate your comments, they are definitely right and helped
me very much.
Thank you.
> Thanks,
> --
> Jean Delvare
> http://khali.linux-fr.org/
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Hi Evgeniy & all,
> > 1* This was 5 months ago. I'd expect Evgeniy's code to have
> > significantly evolved since, so an additional review now would
> > certainly be welcome.
>
> superio core was not changed much, all related changes were posted
> into lm_sensors mail list and discussed.
Well, according to the mailing-list archives, which have a better memory
than I do, I skipped at least one:
http://archives.andrew.net.au/lm-sensors/msg18655.html
So I suspect that this update at least was never reviewed by anyone (on
the sensors list at least).
And while we are at it, this post by Andrew is certainly of interest
too:
http://archives.andrew.net.au/lm-sensors/msg18749.html
> > 3* Some of my objections have been ignored by Evgeniy. Among others,
> > the choice of "sc" as a prefix for the superio stuff is definitely
> > poor and has to be changed.
> >
> > http://archives.andrew.net.au/lm-sensors/msg27847.html
>
> Yep %)
> SuperIO Control - is a good name, sio_ I've seen somewhere...
Sure, sio would be better, or even superio in whole. Anything that
reminds "Super-I/O" is fine with me. sc doesn't.
> GPIO and AccessBus are very simple devices, and I added them just
> because 1. people often asked exactly about GPIO
> 2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too,
> but noone never asked in any mail list about them, but I think it
> worth to implement.
>
> Addind SuperIO itself does not have much sence that it can not be
> tested without at least one logical device, thus I added two.
>
> Porting existing SuperIO devices to the new schema is a very good
> task, but I had only SC1100 processor and PC87366 chip, so I created
> and tested superio chip drivers for them.
The PC87366 has integrated sensors, some of which have to be connected
whatever your configuration: voltage inputs 7 to 10 and third
temperature channel. We have a driver for it in the kernel:
drivers/i2c/chips/pc87360. So if you have such a chip, this is actually
someone you can use as a test for your superio subsystem.
If you can provide a patch which adds your superio core driver and one
which modifies the pc87360 driver to take make use of it, and only that,
this would certainly be easier for everyone (and especially me) to
review your superio code. Once this is in, incremental patches for the
additional features should be easier for you to generate and for the
rest of us to review.
Thanks,
--
Jean Delvare
http://khali.linux-fr.org/
On Tue, 25 Jan 2005 22:40:51 +0100
Jean Delvare <[email protected]> wrote:
> Hi Evgeniy & all,
>
> > > 1* This was 5 months ago. I'd expect Evgeniy's code to have
> > > significantly evolved since, so an additional review now would
> > > certainly be welcome.
> >
> > superio core was not changed much, all related changes were posted
> > into lm_sensors mail list and discussed.
>
> Well, according to the mailing-list archives, which have a better memory
> than I do, I skipped at least one:
>
> http://archives.andrew.net.au/lm-sensors/msg18655.html
>
> So I suspect that this update at least was never reviewed by anyone (on
> the sensors list at least).
I have one rule - if noone answers that it means noone objects,
or it is not interesting for anyone, and thus noone objects.
> And while we are at it, this post by Andrew is certainly of interest
> too:
>
> http://archives.andrew.net.au/lm-sensors/msg18749.html
I believe he commented connector patch mostly - we had some very little
private discussion that time about it.
I've posted connector patch several times to lkml - no answers except
Alan Cox, thus noone objects but patch is very usefull.
> > > 3* Some of my objections have been ignored by Evgeniy. Among others,
> > > the choice of "sc" as a prefix for the superio stuff is definitely
> > > poor and has to be changed.
> > >
> > > http://archives.andrew.net.au/lm-sensors/msg27847.html
> >
> > Yep %)
> > SuperIO Control - is a good name, sio_ I've seen somewhere...
>
> Sure, sio would be better, or even superio in whole. Anything that
> reminds "Super-I/O" is fine with me. sc doesn't.
>
> > GPIO and AccessBus are very simple devices, and I added them just
> > because 1. people often asked exactly about GPIO
> > 2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too,
> > but noone never asked in any mail list about them, but I think it
> > worth to implement.
> >
> > Addind SuperIO itself does not have much sence that it can not be
> > tested without at least one logical device, thus I added two.
> >
> > Porting existing SuperIO devices to the new schema is a very good
> > task, but I had only SC1100 processor and PC87366 chip, so I created
> > and tested superio chip drivers for them.
>
> The PC87366 has integrated sensors, some of which have to be connected
> whatever your configuration: voltage inputs 7 to 10 and third
> temperature channel. We have a driver for it in the kernel:
> drivers/i2c/chips/pc87360. So if you have such a chip, this is actually
> someone you can use as a test for your superio subsystem.
Btw, they appeared almost the same time :)
Difference was about several days...
I have pc8736x logical devices in my TODO list, but they are currently
preempted by acrypto, but I definitely will get it very soon.
> If you can provide a patch which adds your superio core driver and one
> which modifies the pc87360 driver to take make use of it, and only that,
> this would certainly be easier for everyone (and especially me) to
> review your superio code. Once this is in, incremental patches for the
> additional features should be easier for you to generate and for the
> rest of us to review.
pc87360.c can not be used with superio as is, it requires big rewrite,
since you implemented it as part of i2c core,
that is why I created parts that was not touched by your driver.
Since GPIO can be used with w1 it had greater priority.
Your driver is part of i2c core, it just not supposed to be used
in superio, although many hardware routings could be used.
I will use it as a base for other superio logical devices.
> Thanks,
> --
> Jean Delvare
> http://khali.linux-fr.org/
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
> Zeroing can be found easily - the whole structure is NULL pointer,
> and will always panic if accessed(from running superio code),
> but redzoning is only happen on borders,
> and can catch writes over the boards, which is rarely in this case.
As I mentioned the redzoning was a brainfar on my side. Slab debug
code memsets all code with an easily recognizable pattern (which 0 is _NOT_).
So this is totally useless, please don't do it - as all major subsystems
don't do it either.
> Each superio chip is registered with superio core without any devices.
> Each logical device is registered with superio core without any superio
> chip.
>
> Then core checks if some chip is found in some superio device, and
> links
> it to appropriate device.
> So if board has several superio chips(like soekris board) and several
> logical devices in it, then we only have 2 superio small drivers, and
> several
> logical device drivers, but not
> number_of_superio_chips*number_of_logical_devices drivers.
That's how just about any bus driver works so far.
Now somewhere else in the thread I read the a single logical device
might belong to multiple superio devices. Which is kinda odd, but in
that case it's indeed needed.
So please add a big comment explaining that properperty because it
is extemly uncommon, and make 'ptr' in the chain structure typed
instead of void *
> Yes, and it is better than removing module whose structures are in use.
> SuperIO core is asynchronous in it's nature, one can use logical device
> through superio core and remove it's module on other CPU, above loop
> will
> wait untill all reference counters are dropped.
General rule is: increment module reference count while the hardware
is actually in use, and let device structures be allocated by the
bus core so drivers can be freed with them still allocated. That's
how the driver model and thus about every other subsystem works.
On Tue, Jan 25, 2005 at 07:12:55PM +0000, Marcos D. Marado Torres wrote:
> This acpi_power_off issue ( http://lkml.org/lkml/2005/1/11/88 ) still
> happens.
http://bugme.osdl.org/show_bug.cgi?id=4041
Look at that bug report (especially toward the bottom) for the latest
information.
-Barry K. Nathan <[email protected]>
On Wed, 26 January 2005 00:17:34 +0300, Evgeniy Polyakov wrote:
>
> That will catch only simple cases - for the whole picture you need
> to run graph generator from all allowed code pathes, but that
> will require knowledge of the tested system, so it will not and
> actually can not be absolutely generic.
Oh, we both agree on that, although we used different words. The
design actually is as simple as outlined, the messy part is getting
the complete call graph of the kernel in the first place.
I have a good deal of that part done, but the code is ugly and there
are legal issues... but it shows that it's quite possible to do.
J?rn
--
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Someone who sent you a patch needs to learn how to use grep(1). There are
18 patches listed by grep -l it_timer patches/*; giving up.
-- wli
drivers/char/mmtimer.c: In function `reschedule_periodic_timer':
drivers/char/mmtimer.c:423: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:429: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:429: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:435: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `mmtimer_interrupt':
drivers/char/mmtimer.c:471: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `mmtimer_tasklet':
drivers/char/mmtimer.c:508: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:516: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_create':
drivers/char/mmtimer.c:527: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_del':
drivers/char/mmtimer.c:538: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:539: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:547: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:548: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_get':
drivers/char/mmtimer.c:561: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:569: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:570: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_set':
drivers/char/mmtimer.c:643: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:644: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:645: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:646: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:652: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:655: error: structure has no member named `it_timer'
make[4]: *** [drivers/char/mmtimer.o] Error 1
make[3]: *** [drivers/char] Error 2
make[2]: *** [drivers] Error 2
make[2]: *** Waiting for unfinished jobs....
On Mon, 2005-01-24 at 02:15 -0800, Andrew Morton wrote:
> ppc64-use-kref-for-device_node-refcounting.patch
> ppc64: use kref for device_node refcounting
This introduced an unbalanced get/put in of_add_node which would cause
newly-added device nodes to be prematurely freed. Sorry for the
screwup, a more rigorously tested fix follows.
Signed-off-by: Nathan Lynch <[email protected]>
---
diff -puN arch/ppc64/kernel/prom.c~fix-kref-devnode arch/ppc64/kernel/prom.c
--- linux-2.6.11-rc2-mm1/arch/ppc64/kernel/prom.c~fix-kref-devnode 2005-01-25 21:10:50.000000000 -0600
+++ linux-2.6.11-rc2-mm1-nathanl/arch/ppc64/kernel/prom.c 2005-01-25 21:14:02.000000000 -0600
@@ -1771,6 +1771,7 @@ int of_add_node(const char *path, struct
np->properties = proplist;
OF_MARK_DYNAMIC(np);
kref_init(&np->kref);
+ of_node_get(np);
np->parent = derive_parent(path);
if (!np->parent) {
kfree(np);
_
On Tuesday 25 January 2005 16:14, Evgeniy Polyakov wrote:
> On Tue, 25 Jan 2005 11:11:42 -0500
> Dmitry Torokhov <[email protected]> wrote:
>
> > On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
> > <[email protected]> wrote:
> > > On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > > > > +static void pc8736x_fini(void)
> > > > > > +{
> > > > > > + sc_del_sc_dev(&pc8736x_dev);
> > > > > > +
> > > > > > + while (atomic_read(&pc8736x_dev.refcnt)) {
> > > > > > + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > > > > > + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > > > > > +
> > > > > > + set_current_state(TASK_INTERRUPTIBLE);
> > > > > > + schedule_timeout(HZ);
> > > > > > +
> > > > > > + if (current->flags & PF_FREEZE)
> > > > > > + refrigerator(PF_FREEZE);
> > > > > > +
> > > > > > + if (signal_pending(current))
> > > > > > + flush_signals(current);
> > > > > > + }
> > > > > > +}
> > > > > >
> > > > > > And who gurantess this won't deadlock? Please use a dynamically allocated
> > > > > > driver model device and it's refcounting, thanks.
> > > > >
> > > > > Sigh.
> > > > >
> > > > > Christoph, please read the code before doing such comments.
> > > > > I very respect your review and opinion, but only until you respect
> > > > > others.
> > > >
> > > > The code above pretty much means you can keep rmmod stalled forever.
> > >
> > > Yes, and it is better than removing module whose structures are in use.
> > > SuperIO core is asynchronous in it's nature, one can use logical device
> > > through superio core and remove it's module on other CPU, above loop
> > > will wait untill all reference counters are dropped.
> >
> > I have a slightly different concern - the superio is a completely new
> > subsystem and it should be integtrated with the driver model
> > ("superio" bus?). Right now it looks like it is reimplementing most of
> > the abstractions (device lists, driver lists, matching, probing).
> > Moving to driver model significatntly affects lifetime rules for the
> > objects, etc. etc. and will definitely not allow code such as above.
> >
> > It would be nice it we get things right from the start.
>
> bus model is not good here - we need bus in each logical device and
> bus in each superio chip(or at least second case).
> Each bus bus have some crosslinking to devices in other buses,
> and each new device
> must be checked in each bus and probably added to each device...
>
> It is not like I see it.
>
> Consider folowing example:
> each device from set A belongs to each device from set B.
> n <-> n, it is not the case when one bus can handle all features.
>
> That is why I did not use driver model there.
> It is specific design feature, which is proven to work.
>
Ok, I briefly looked over the patches and that is what I understand
(please correct me where I am wrong):
- you have superio chips which are containers providing set of interfaces;
- you have superio chip driver that detects superio chip and manages
(enables/disables) individual interfaces.
- you have set of interface drivers (gpio, acb) that bind to individual
superio interfaces and provide unified userspace interface that allows
reading, writing and analog of ioctl.
So the question is why you can't have superio bus where superio chips
register their individual interfaces as individual devices. gpio, acb, etc
are drivers that bind to superio devices and create class devices gpio.
You could have:
sys
|-bus
| |-superio
| | |-devices
| | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
| | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
| | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
| | |-drivers
| | | |-gpio
| | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
| | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
| | | |-acb
| | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
|
|-class
| |-gpio
| | |-gpio0
| | |-gpio1
gpioX have control and data attributes that allow reading and writing...
Am I missing something?
--
Dmitry
On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:
> > > I have a slightly different concern - the superio is a completely new
> > > subsystem and it should be integtrated with the driver model
> > > ("superio" bus?). Right now it looks like it is reimplementing most of
> > > the abstractions (device lists, driver lists, matching, probing).
> > > Moving to driver model significatntly affects lifetime rules for the
> > > objects, etc. etc. and will definitely not allow code such as above.
> > >
> > > It would be nice it we get things right from the start.
> >
> > bus model is not good here - we need bus in each logical device and
> > bus in each superio chip(or at least second case).
> > Each bus bus have some crosslinking to devices in other buses,
> > and each new device
> > must be checked in each bus and probably added to each device...
> >
> > It is not like I see it.
> >
> > Consider folowing example:
> > each device from set A belongs to each device from set B.
> > n <-> n, it is not the case when one bus can handle all features.
> >
> > That is why I did not use driver model there.
> > It is specific design feature, which is proven to work.
> >
>
> Ok, I briefly looked over the patches and that is what I understand
> (please correct me where I am wrong):
>
> - you have superio chips which are containers providing set of interfaces;
> - you have superio chip driver that detects superio chip and manages
> (enables/disables) individual interfaces.
> - you have set of interface drivers (gpio, acb) that bind to individual
> superio interfaces and provide unified userspace interface that allows
> reading, writing and analog of ioctl.
>
> So the question is why you can't have superio bus where superio chips
> register their individual interfaces as individual devices. gpio, acb, etc
> are drivers that bind to superio devices and create class devices gpio.
>
> You could have:
>
> sys
> |-bus
> | |-superio
> | | |-devices
> | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> | | |-drivers
> | | | |-gpio
> | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> | | | |-acb
> | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> |
> |-class
> | |-gpio
> | | |-gpio0
> | | |-gpio1
>
> gpioX have control and data attributes that allow reading and writing...
>
> Am I missing something?
You try to create n <-> 1 relation, but superio by design supposed to be
n <-> n.
Above schema does not allow linking from each logical device to
appropriate superio chips
or vice versa - sc chips do not have link to it's logical devices.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Tue, 2005-01-25 at 22:42 +0000, Christoph Hellwig wrote:
> > Zeroing can be found easily - the whole structure is NULL pointer,
> > and will always panic if accessed(from running superio code),
> > but redzoning is only happen on borders,
> > and can catch writes over the boards, which is rarely in this case.
>
> As I mentioned the redzoning was a brainfar on my side. Slab debug
> code memsets all code with an easily recognizable pattern (which 0 is _NOT_).
>
> So this is totally useless, please don't do it - as all major subsystems
> don't do it either.
Ok, I do not insist.
> > Each superio chip is registered with superio core without any devices.
> > Each logical device is registered with superio core without any superio
> > chip.
> >
> > Then core checks if some chip is found in some superio device, and
> > links
> > it to appropriate device.
> > So if board has several superio chips(like soekris board) and several
> > logical devices in it, then we only have 2 superio small drivers, and
> > several
> > logical device drivers, but not
> > number_of_superio_chips*number_of_logical_devices drivers.
>
> That's how just about any bus driver works so far.
>
> Now somewhere else in the thread I read the a single logical device
> might belong to multiple superio devices. Which is kinda odd, but in
> that case it's indeed needed.
>
> So please add a big comment explaining that properperty because it
> is extemly uncommon, and make 'ptr' in the chain structure typed
> instead of void *
Ok.
> > Yes, and it is better than removing module whose structures are in use.
> > SuperIO core is asynchronous in it's nature, one can use logical device
> > through superio core and remove it's module on other CPU, above loop
> > will
> > wait untill all reference counters are dropped.
>
> General rule is: increment module reference count while the hardware
> is actually in use, and let device structures be allocated by the
> bus core so drivers can be freed with them still allocated. That's
> how the driver model and thus about every other subsystem works.
It is not general rule - network stack does not have such mechanism,
which is
very good, I doubt each block device module increment it's module
reference
when it catch a request...
It is internal structure that has reference counter, not module itself,
and this
structure may be in use, when module is unloaded, thus unloading must
wait,
untill all it's structures are freed.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
Quoting r. Andi Kleen <[email protected]>:
> Subject: Re: [PATCH] move common compat ioctls to hash
>
> On Mon, Jan 24, 2005 at 10:26:09PM +0200, Michael S. Tsirkin wrote:
> > Hi!
> > The new ioctl code in fs/compat.c can be streamlined a little
> > using the compat hash instead of an explicit switch statement.
> >
> > The attached patch is against 2.6.11-rc2-bk2.
> > Andi, could you please comment? Does this make sence?
>
> Problem is that when a compat_ioctl handler returns -EINVAL
> instead of -ENOIOCTLCMD on unknown ioctl it won't check the common
> ones.
>
> I fear this mistake would be common, that is why I put in the switch.
>
> -Andi
Still, many drivers still need the compat hash lookup to work
properly, and these still require -ENOIOCTLCMD to work properly.
So is it worth it wasting CPU cycles working around only part of the problem?
How about:
1. Adding a comment in fs.h
2. Changing unlocked_ioctl to behave in the same way as compat_ioctl
(this will help since unlocked_ioctl will be well tested),
something along the lines of my old patch below [its against 2.6.11-rc1-bk5].
As a bonus, I expect a small speedup in code using unlocked_ioctl
(as well as compat_ioctl) for datapath things like usb transfers.
Andy, if this sounds convincing, let me know and I'll build a real patch.
MST
diff -rup linux-2.6.10-orig/fs/ioctl.c linux-2.6.10-ioctl-sym/fs/ioctl.c
--- linux-2.6.10-orig/fs/ioctl.c 2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/ioctl.c 2005-01-18 10:51:55.690372984 +0200
@@ -24,12 +24,7 @@ static long do_ioctl(struct file *filp,
if (!filp->f_op)
goto out;
- if (filp->f_op->unlocked_ioctl) {
- error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
- if (error == -ENOIOCTLCMD)
- error = -EINVAL;
- goto out;
- } else if (filp->f_op->ioctl) {
+ if (filp->f_op->ioctl) {
lock_kernel();
error = filp->f_op->ioctl(filp->f_dentry->d_inode,
filp, cmd, arg);
@@ -93,6 +91,12 @@ asmlinkage long sys_ioctl(unsigned int f
if (error)
goto out_fput;
+ if (filp->f_op && filp->f_op->unlocked_ioctl) {
+ error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
+ if (error != -ENOIOCTLCMD)
+ goto out_fput;
+ }
+
switch (cmd) {
case FIOCLEX:
set_close_on_exec(fd, 1);
--
I dont speak for Mellanox.
Hi Evgeniy,
> > So I suspect that this update at least was never reviewed by anyone (on
> > the sensors list at least).
>
> I have one rule - if noone answers that it means noone objects,
> or it is not interesting for anyone, and thus noone objects.
Broken rule IMHO. This might be fine for your own projects, but doesn't
work at all for the kernel. Silence might not mean that everyone agrees.
Rather, it could mean that either people are just not interested at all,
or they are too busy to review a whole new subsystem (or more) at the
moment. Believe me, kernel folks are very, very busy.
> I have pc8736x logical devices in my TODO list, but they are currently
> preempted by acrypto, but I definitely will get it very soon.
I don't think you get me. Your personal priorities are unimportant when
you are asking for code review and merge into the main kernel tree. What
matters is that parts are presented correctly and added in small chunks
and in the right order, so as to minimize the time it takes to Greg and
others to understand, review and accept it.
One year ago I learnt this the hard way myself. I realize how deep my
misunderstanding of the situation was back then, and now praise Greg for
the good lesson - however tough it was for me at that time - each time I
now send a kernel patch the right way and get it accepted.
So, make yourself a favor and comply with what the kernel folks expect
from you. They won't change for you.
> > If you can provide a patch which adds your superio core driver and one
> > which modifies the pc87360 driver to take make use of it, and only that,
> > this would certainly be easier for everyone (and especially me) to
> > review your superio code. Once this is in, incremental patches for the
> > additional features should be easier for you to generate and for the
> > rest of us to review.
>
> pc87360.c can not be used with superio as is, it requires big rewrite,
> since you implemented it as part of i2c core,
> that is why I created parts that was not touched by your driver.
Again, you clearly don't get it. The pc87360 driver does *not* require a
big rewrite. Without even looking at your superio code again, I can tell
that it is necessarily broken if every driver which accesses the superio
address space at the moment needs a big rewrite.
The pc87360 driver only really uses the superio for hardware
identification and then to get a couple configuration values (such as
subdevice I/O addresses) at startup, and then leaves it alone forever.
If we has a dedicated superio driver, it would need to provide an
interface to read, and eventually write, these values, as a replacement
for the savage direct accesses we do for now. Period. Anything else
might be nice or useful for other logical devices (such as GPIOs) but is
not strictly necessary at first.
I do not deny that these Super-I/O integrated sensors are not using the
SMBus and as such do not truly belong to the i2c subsystem. It just
happens that, for now and for historical reasons, the i2c subsystem is
also where all hardware monitoring drivers are. That might (hopefully)
change in the future, but this is a completely different problem. One
thing at a time please.
> Your driver is part of i2c core, it just not supposed to be used
> in superio, although many hardware routings could be used.
Again, some drivers in the i2c subsystem use ISA accesses; others need to
poke a couple PCI configuration registers. We did not move these drivers
to the ISA (is there even one?) or PCI subsystems. Before anything else,
these drivers are hardware monitoring drivers, and such drivers belong -
for now - to the i2c subsystem, until we can separate the i2c subsystem
from the hardware monitoring function more clearly.
So, the pc87360, it87, smsc47m1 and w83627hf drivers are not going to
move to the "superio subsystem", nor are they going to be rewritten
for it. Superio chips are only a new way to access the subdevices. What
we need for them is an extension of the request_region/release_region
mechanism, because superios introduce a two-level addressing scheme. And
this is about it.
Thanks,
--
Jean Delvare
On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> I have one rule - if noone answers that it means noone objects,
> or it is not interesting for anyone, and thus noone objects.
That's simply not true. The amount of patches submitted is extremly
huge and the reviewers don't have time to look at everythning.
If no one replies it simply means no one has looked at it in enough
detail to comment yet.
On Wed, 2005-01-26 at 10:55 +0100, Jean Delvare wrote:
> Hi Evgeniy,
>
> > > So I suspect that this update at least was never reviewed by anyone (on
> > > the sensors list at least).
> >
> > I have one rule - if noone answers that it means noone objects,
> > or it is not interesting for anyone, and thus noone objects.
>
> Broken rule IMHO. This might be fine for your own projects, but doesn't
> work at all for the kernel. Silence might not mean that everyone agrees.
> Rather, it could mean that either people are just not interested at all,
> or they are too busy to review a whole new subsystem (or more) at the
> moment. Believe me, kernel folks are very, very busy.
Sigh.
I presented the code.
Several times in special mail list.
Only problem that it was not sent to lkml, where there are
too many noise and flood. That is why while digging through it several
years ago I decided to drop this mail list.
> > I have pc8736x logical devices in my TODO list, but they are currently
> > preempted by acrypto, but I definitely will get it very soon.
>
> I don't think you get me. Your personal priorities are unimportant when
> you are asking for code review and merge into the main kernel tree. What
> matters is that parts are presented correctly and added in small chunks
> and in the right order, so as to minimize the time it takes to Greg and
> others to understand, review and accept it.
>
> One year ago I learnt this the hard way myself. I realize how deep my
> misunderstanding of the situation was back then, and now praise Greg for
> the good lesson - however tough it was for me at that time - each time I
> now send a kernel patch the right way and get it accepted.
>
> So, make yourself a favor and comply with what the kernel folks expect
> from you. They won't change for you.
Mdee...
I do not understand you, what are you trying to say? Waht is wrong?
I wrote the code.
I presented it.
I presented it again.
I presented it yeat another again.
First time people answered, then - not.
I ask for inclusion. It is included, and ohh now people recall,
that they wanted to complain.
Ok, I want to listen what technical problems do you see?
> > > If you can provide a patch which adds your superio core driver and one
> > > which modifies the pc87360 driver to take make use of it, and only that,
> > > this would certainly be easier for everyone (and especially me) to
> > > review your superio code. Once this is in, incremental patches for the
> > > additional features should be easier for you to generate and for the
> > > rest of us to review.
> >
> > pc87360.c can not be used with superio as is, it requires big rewrite,
> > since you implemented it as part of i2c core,
> > that is why I created parts that was not touched by your driver.
>
> Again, you clearly don't get it. The pc87360 driver does *not* require a
> big rewrite. Without even looking at your superio code again, I can tell
> that it is necessarily broken if every driver which accesses the superio
> address space at the moment needs a big rewrite.
>
> The pc87360 driver only really uses the superio for hardware
> identification and then to get a couple configuration values (such as
> subdevice I/O addresses) at startup, and then leaves it alone forever.
> If we has a dedicated superio driver, it would need to provide an
> interface to read, and eventually write, these values, as a replacement
> for the savage direct accesses we do for now. Period. Anything else
> might be nice or useful for other logical devices (such as GPIOs) but is
> not strictly necessary at first.
>
> I do not deny that these Super-I/O integrated sensors are not using the
> SMBus and as such do not truly belong to the i2c subsystem. It just
> happens that, for now and for historical reasons, the i2c subsystem is
> also where all hardware monitoring drivers are. That might (hopefully)
> change in the future, but this is a completely different problem. One
> thing at a time please.
Sigh.
Jean, it looks like you forget how superio is designed.
Your pc87360 driver is all in one big piese of code, superio
is splitted into absolutely separated modules - _one_ for superio chip,
and _several_ for logical devices.
I need to split your driver into at least 5 parts - pc8736x
initialisation(superio has it), i2c part(should be removed from superio
code),
fan logical device(separate part), voltage monitor logical device
(separate part)
and temperature monitor logical device(separate part).
They are just separate modules, it is design feature to use _the_
_same_,
for example, voltage monitor module with _any_ number of existent
superio chips.
> > Your driver is part of i2c core, it just not supposed to be used
> > in superio, although many hardware routings could be used.
>
> Again, some drivers in the i2c subsystem use ISA accesses; others need to
> poke a couple PCI configuration registers. We did not move these drivers
> to the ISA (is there even one?) or PCI subsystems. Before anything else,
> these drivers are hardware monitoring drivers, and such drivers belong -
> for now - to the i2c subsystem, until we can separate the i2c subsystem
> from the hardware monitoring function more clearly.
>
> So, the pc87360, it87, smsc47m1 and w83627hf drivers are not going to
> move to the "superio subsystem", nor are they going to be rewritten
> for it. Superio chips are only a new way to access the subdevices. What
> we need for them is an extension of the request_region/release_region
> mechanism, because superios introduce a two-level addressing scheme. And
> this is about it.
And that will end up having tons of duplicated code in each driver:
temp monitor in A, temp monitor in B and so on...
volt monitor in A, volt monitor in B and so on...
...
Jean, we already discussed it a bit in lm_sensors mail list AFAR...
> Thanks,
> --
> Jean Delvare
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Wed, 2005-01-26 at 10:14 +0000, Christoph Hellwig wrote:
> On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > I have one rule - if noone answers that it means noone objects,
> > or it is not interesting for anyone, and thus noone objects.
>
> That's simply not true. The amount of patches submitted is extremly
> huge and the reviewers don't have time to look at everythning.
>
> If no one replies it simply means no one has looked at it in enough
> detail to comment yet.
That is why I resent it several times.
Then I asked for inclusion.
I never send it to lkml just because simple static/non static + module
name
discussion in lkml already overflowed into more than 20 messages...
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Wed, Jan 26, 2005 at 10:14:34AM +0000, Christoph Hellwig wrote:
> That's simply not true. The amount of patches submitted is extremly
> huge and the reviewers don't have time to look at everythning.
>
> If no one replies it simply means no one has looked at it in enough
> detail to comment yet.
How do people get to know this? Grape vines and crystal balls are
inherently unreliable.
I think that if someone overlooks the patches when they're on the mailing
lists and then complains when they're merged into the kernel, they have
very little justification when trying to make it the patch submitters
problem. It's clearly an overall failing of the community to have enough
resources to review the patches before inclusion.
Frequently I end up with the situation where *NO* *ONE* seems interested
in my patches and I throw them at Linus anyway after months have gone by.
Maybe I'm just lucky that no one bothers to read my patches or everyone
is implicitly exstatic with them. Nevertheless, I'm forced by the lack
of response from LKML to follow precisely the same rule - no response
implies people are happy. In reality, not doing so would mean I'd never
get any patches merged which is unacceptable.
So, if the community has a problem with enough time to review patches,
the community must get more (good) patch reviewers. We can't go around
blaming the patch submitters for a community failing.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Wed, 26 Jan 2005 11:31:07 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> On Tue, 2005-01-25 at 22:42 +0000, Christoph Hellwig wrote:
> > > Yes, and it is better than removing module whose structures are in use.
> > > SuperIO core is asynchronous in it's nature, one can use logical device
> > > through superio core and remove it's module on other CPU, above loop
> > > will
> > > wait untill all reference counters are dropped.
> >
> > General rule is: increment module reference count while the hardware
> > is actually in use, and let device structures be allocated by the
> > bus core so drivers can be freed with them still allocated. That's
> > how the driver model and thus about every other subsystem works.
>
> It is not general rule - network stack does not have such mechanism,
> which is
> very good, I doubt each block device module increment it's module
> reference
> when it catch a request...
> It is internal structure that has reference counter, not module itself,
> and this
> structure may be in use, when module is unloaded, thus unloading must
> wait,
> untill all it's structures are freed.
>
No, it does not necessarily has to wait. You can unload driver at any
time if you care to mark all its devices as "dead" and you have
generic release function in a separate module that does not get
unloaded until last registered device has been destroyed. Look for
example at serio code. I think USB is about the same.
--
Dmitry
On Wed, 26 Jan 2005 11:25:02 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:
>
> > > > I have a slightly different concern - the superio is a completely new
> > > > subsystem and it should be integtrated with the driver model
> > > > ("superio" bus?). Right now it looks like it is reimplementing most of
> > > > the abstractions (device lists, driver lists, matching, probing).
> > > > Moving to driver model significatntly affects lifetime rules for the
> > > > objects, etc. etc. and will definitely not allow code such as above.
> > > >
> > > > It would be nice it we get things right from the start.
> > >
> > > bus model is not good here - we need bus in each logical device and
> > > bus in each superio chip(or at least second case).
> > > Each bus bus have some crosslinking to devices in other buses,
> > > and each new device
> > > must be checked in each bus and probably added to each device...
> > >
> > > It is not like I see it.
> > >
> > > Consider folowing example:
> > > each device from set A belongs to each device from set B.
> > > n <-> n, it is not the case when one bus can handle all features.
> > >
> > > That is why I did not use driver model there.
> > > It is specific design feature, which is proven to work.
> > >
> >
> > Ok, I briefly looked over the patches and that is what I understand
> > (please correct me where I am wrong):
> >
> > - you have superio chips which are containers providing set of interfaces;
> > - you have superio chip driver that detects superio chip and manages
> > (enables/disables) individual interfaces.
> > - you have set of interface drivers (gpio, acb) that bind to individual
> > superio interfaces and provide unified userspace interface that allows
> > reading, writing and analog of ioctl.
> >
> > So the question is why you can't have superio bus where superio chips
> > register their individual interfaces as individual devices. gpio, acb, etc
> > are drivers that bind to superio devices and create class devices gpio.
> >
> > You could have:
> >
> > sys
> > |-bus
> > | |-superio
> > | | |-devices
> > | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> > | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> > | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> > | | |-drivers
> > | | | |-gpio
> > | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> > | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> > | | | |-acb
> > | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> > |
> > |-class
> > | |-gpio
> > | | |-gpio0
> > | | |-gpio1
> >
> > gpioX have control and data attributes that allow reading and writing...
> >
> > Am I missing something?
>
> You try to create n <-> 1 relation, but superio by design supposed to be
> n <-> n.
What design? Hardware design or present implementation design?
> Above schema does not allow linking from each logical device to
> appropriate superio chips
> or vice versa - sc chips do not have link to it's logical devices.
>
sc chip does have a link to its logical devices - look at 0000:02:03.0
PCI device in the picture above - that your SuperIO chip with 2
interfaces. Interface, when bound to a superio driver creates gpio
class device which in turn has link to physical device (here one of
the SuperIO interfaces).
Yes, I am trying to do 1 - n relationship. I do not understand why
logical device has to span across several physical devices. With the
exception of device mapper/raid you don't have a logical device span
several physical devices, with everything else there is a parent that
has several children.
You have a PCI bus that has several PCI devices, one of them happens
to be a IDE host controller with 2 channels connected to it. The other
is your SuperIO chip with 2 GPIO pins and something else, and another
SuperIO chip with 3 GIPO pins. Let's say you 1st chip monitors
temperature in the case and the second interfaces wth some custom
equipment measuring some thersholds in some chemical process. Are you
saying that all 5 GPIO pins should be presented as one logical device
that provides 5 outputs not related to each other? No, you have 5
distinct devices with similar interfaces providing 5 distinct reads.
Userspace may chose to group them somehow, based on external
information that kernel does not have, but that's it. Kernel only
provides uniform interface.
--
Dmitry
On Wed, 26 Jan 2005 13:59:17 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> On Wed, 2005-01-26 at 10:14 +0000, Christoph Hellwig wrote:
> > On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > > I have one rule - if noone answers that it means noone objects,
> > > or it is not interesting for anyone, and thus noone objects.
> >
> > That's simply not true. The amount of patches submitted is extremly
> > huge and the reviewers don't have time to look at everythning.
> >
> > If no one replies it simply means no one has looked at it in enough
> > detail to comment yet.
>
> That is why I resent it several times.
> Then I asked for inclusion.
>
> I never send it to lkml just because simple static/non static + module
> name
> discussion in lkml already overflowed into more than 20 messages...
Well, not everyone is subscribed to lm_sensors mailing list but
nonetheless are interested when a new subsystem is introduced into the
kernel. There several established subsystems (network, USB, ide) whose
maintainers people trust either because of the good track record or
because it affects small number of people so the main discussion is
kept on special lists. But even then most patches are presented on
LKML when issues ironed out on special list.
With a new subsystem it is wise to present it to LKML so it gets wider coverage.
--
Dmitry
Hi Evgeniy,
> I presented the code.
> Several times in special mail list.
That's true. Except that the second time (at least) you didn't find
anyone to review it. Also note that your patches are about superio, gpio
and now access bus. The list is dedicated to hardware monitoring. This
is no exact match, although it happens that some superio chips include
hardware monitoring logical devices. So I reviewed the part I think I
could help with, and skipped the rest (and I did tell the you, and the
list, that I had).
> Only problem that it was not sent to lkml, where there are
> too many noise and flood. That is why while digging through it several
> years ago I decided to drop this mail list.
I agree that there is a heavy traffic on LKML - I am not subscribed
myself just because of that. However, when one introduces a completely
new subsystem, it definitely needs review by folks that have way more
knowledge about the kernel internals than I do - expecially about the
(bus) driver model.
> I do not understand you, what are you trying to say? Waht is wrong?
> I wrote the code.
> I presented it.
> I presented it again.
> I presented it yeat another again.
>
> First time people answered, then - not.
OK, blame me for having a day job, a girlfriend and a family. Blame me
for not having the necessary time and knowledge to review your code.
And then think about it again. Maybe you did not present it to the right
person(s). Maybe you did not present it in the correct form. Maybe you
didn't properly explain what problem you were trying to solve - and
failed to catch people's attention because of that. And maybe you
should not have ignored some of my comments - and others'. I would
invite you to read your own recent posts to the LKML again. Most
objections you have received about your code - some of which were so
blantantly valid (several drivers with the same name is fine, no
kidding) - you first denied that there were any problem, then grumbled,
then accepted to change but just not to make any trouble - not because
you were wrong. You are not going anywhere here with this attitude.
Sure, we, kernel developers as a whole, lack time to properly review all
the code that is sent to us. Even me, and I probably receive one
hundredth of what Greg, Andrew or Linus receive. And now what? That's
the way it is and we (and you) have to live with it. If you want the
situation to improve, you can volunteer to review some code. Andrew's
broken-out directories and LKML are full of patches that need review. Or
pick one subsystem and track the patches applied to it. Really, do not
hesitate to help. You certainly will learn much about kernel code review
by doing so, and your own submissions are likely to be significantly
better thanks to that. My story exactly.
> I ask for inclusion. It is included, and ohh now people recall,
> that they wanted to complain.
What other choice do they have at this point? Ignore or complain. I
definitely prefer them to complain if they have a reason to - and the
same would apply if it was my code and not yours.
Note that I don't blame Greg for pushing the code into Andrew's tree.
This is what this tree is for, and now your patches got some exposure
and you have objections to work on, to say the least. I also admit that
some people here are being a little harsh, but I believe that each one
of us is doing his/her best to improve the kernel. It just happens that
our best isn't always as good as one would want.
> Ok, I want to listen what technical problems do you see?
As I explained before, I would like to see your superio subsystem
integrate properly with existing drivers that need it before you attempt
to add more functions on top of it. And I want a full documentation of
your superio subsystem to be part of the patchset. It seems that most
people here didn't get what you were doing and why you were doing it
(at least I wasn't alone ;)), so obviously a complete documentation
would be more than welcome - needed would in fact be the appropriate
term.
> Jean, it looks like you forget how superio is designed.
> Your pc87360 driver is all in one big piese of code, superio
> is splitted into absolutely separated modules - _one_ for superio chip,
> and _several_ for logical devices.
>
> I need to split your driver into at least 5 parts - pc8736x
> initialisation(superio has it), i2c part(should be removed from superio
> code), fan logical device(separate part), voltage monitor logical device
> (separate part) and temperature monitor logical device (separate part).
The whole thing is a single driver because it achieves one goal. The fact
that National Semiconductor decided to use three different logical
devices for temperatures, voltages and fans is an implementation detail.
This alone doesn't justify a split of the source code. The "superio
chip" part is what you have been working on and I agree it was needed.
And I agree that the superio access has to be moved from my pc87360
driver (and other similar drivers) to your superio driver.
You do not *have* to separate all the parts. One single driver can
request several logical devices, and this is precisely what I want us to
do here. I agree that it could make sense to separate the logical
devices on a per device (and driver) basis, if it allows us to reuse the
code more easily. It is however not a requirement, that I can see.
> They are just separate modules, it is design feature to use _the_ _same_,
> for example, voltage monitor module with _any_ number of existent superio
> chips.
It isn't the first time you say that, and I have to say I don't much
get where you want to go. The hardware monitoring logical devices are
completely different between PC8736x, IT87xxF, W836x7(T)HF and 47M1xx
superio devices, just like the various other hardware monitoring chips
are different. There is no code to be shared here, so nothing is
duplicated.
Maybe it is different with gpio or access bus? Is there some standard
register organization among the various chip makers? I don't know
these, so I cannot tell.
> And that will end up having tons of duplicated code in each driver:
> temp monitor in A, temp monitor in B and so on...
> volt monitor in A, volt monitor in B and so on...
There is no logical device-based duplicated code in the superio hardware
monitoring drivers at the moment, unless you see things I do not (if you
do please let me know). The only thing that is duplicated accross the
drivers is the superio accesses, agreed, and I am glad that your unified
superio driver will put an end to this.
> Jean, we already discussed it a bit in lm_sensors mail list AFAR...
Yes, 5 months ago, and we did not exactly agree. And we obviously still
do not agree.
Don't get me wrong, I am not saying that I don't want your code in the
kernel. I am actually interested in it (the base superio part, in fact).
All I am asking for is that you put some efforts in presenting your code
correctly, splitting it the way it has to be, and getting it into the
kernel step by step. You are not going to get any support from me by
pretending that the superio hardware monitoring drivers need a full
rewrite to accomodate with your unified superio driver - because I know
it cannot be true. If you can provide a first patchset with core superio
driver, documentation of it, and *minimum* updates of the pc87360 driver
to make use of it, you can be sure I will review it with great care.
Thanks,
--
Jean Delvare
On Wed, 2005-01-26 at 08:32 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 11:31:07 +0300, Evgeniy Polyakov
> <[email protected]> wrote:
> > On Tue, 2005-01-25 at 22:42 +0000, Christoph Hellwig wrote:
> > > > Yes, and it is better than removing module whose structures are in use.
> > > > SuperIO core is asynchronous in it's nature, one can use logical device
> > > > through superio core and remove it's module on other CPU, above loop
> > > > will
> > > > wait untill all reference counters are dropped.
> > >
> > > General rule is: increment module reference count while the hardware
> > > is actually in use, and let device structures be allocated by the
> > > bus core so drivers can be freed with them still allocated. That's
> > > how the driver model and thus about every other subsystem works.
> >
> > It is not general rule - network stack does not have such mechanism,
> > which is
> > very good, I doubt each block device module increment it's module
> > reference
> > when it catch a request...
> > It is internal structure that has reference counter, not module itself,
> > and this
> > structure may be in use, when module is unloaded, thus unloading must
> > wait,
> > untill all it's structures are freed.
> >
>
> No, it does not necessarily has to wait. You can unload driver at any
> time if you care to mark all its devices as "dead" and you have
> generic release function in a separate module that does not get
> unloaded until last registered device has been destroyed. Look for
> example at serio code. I think USB is about the same.
>
It is only because those structures can live outside the driver.
Like skb can live without even any network driver loaded.
Above case is similar, but structure is binded to the module, and can
be
requested outside the world.
Consider as example network stack:
netdev_wait_allrefs() waits until all references are gone, it is
called
when device has NETREG_UNREGISTERING state.
Very clean example is virtual devices here(tunnels, vlan) - it is
exactly the same
as logical/superio devices in superio core.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Wed, 2005-01-26 at 08:46 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 11:25:02 +0300, Evgeniy Polyakov
> <[email protected]> wrote:
> > On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:
> >
> > > > > I have a slightly different concern - the superio is a completely new
> > > > > subsystem and it should be integtrated with the driver model
> > > > > ("superio" bus?). Right now it looks like it is reimplementing most of
> > > > > the abstractions (device lists, driver lists, matching, probing).
> > > > > Moving to driver model significatntly affects lifetime rules for the
> > > > > objects, etc. etc. and will definitely not allow code such as above.
> > > > >
> > > > > It would be nice it we get things right from the start.
> > > >
> > > > bus model is not good here - we need bus in each logical device and
> > > > bus in each superio chip(or at least second case).
> > > > Each bus bus have some crosslinking to devices in other buses,
> > > > and each new device
> > > > must be checked in each bus and probably added to each device...
> > > >
> > > > It is not like I see it.
> > > >
> > > > Consider folowing example:
> > > > each device from set A belongs to each device from set B.
> > > > n <-> n, it is not the case when one bus can handle all features.
> > > >
> > > > That is why I did not use driver model there.
> > > > It is specific design feature, which is proven to work.
> > > >
> > >
> > > Ok, I briefly looked over the patches and that is what I understand
> > > (please correct me where I am wrong):
> > >
> > > - you have superio chips which are containers providing set of interfaces;
> > > - you have superio chip driver that detects superio chip and manages
> > > (enables/disables) individual interfaces.
> > > - you have set of interface drivers (gpio, acb) that bind to individual
> > > superio interfaces and provide unified userspace interface that allows
> > > reading, writing and analog of ioctl.
> > >
> > > So the question is why you can't have superio bus where superio chips
> > > register their individual interfaces as individual devices. gpio, acb, etc
> > > are drivers that bind to superio devices and create class devices gpio.
> > >
> > > You could have:
> > >
> > > sys
> > > |-bus
> > > | |-superio
> > > | | |-devices
> > > | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> > > | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> > > | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> > > | | |-drivers
> > > | | | |-gpio
> > > | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> > > | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> > > | | | |-acb
> > > | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> > > |
> > > |-class
> > > | |-gpio
> > > | | |-gpio0
> > > | | |-gpio1
> > >
> > > gpioX have control and data attributes that allow reading and writing...
> > >
> > > Am I missing something?
> >
> > You try to create n <-> 1 relation, but superio by design supposed to be
> > n <-> n.
>
> What design? Hardware design or present implementation design?
Hardware: each superio chip can have exactly the same logical devices
like any
other(actually it is standard, which is not always followed). I mean not
the same device
set, but logical devices itself - voltage monitors are the same for any
standard superio chip.
So we have many chips with the same set of the similar hardware.
Reverse relation is created when we want to keep only
number_od_superio_chips + number_of_logical_device number of drivers,
but not it's multiplication.
> > Above schema does not allow linking from each logical device to
> > appropriate superio chips
> > or vice versa - sc chips do not have link to it's logical devices.
> >
>
> sc chip does have a link to its logical devices - look at 0000:02:03.0
> PCI device in the picture above - that your SuperIO chip with 2
> interfaces. Interface, when bound to a superio driver creates gpio
> class device which in turn has link to physical device (here one of
> the SuperIO interfaces).
>
>
> Yes, I am trying to do 1 - n relationship. I do not understand why
> logical device has to span across several physical devices. With the
> exception of device mapper/raid you don't have a logical device span
> several physical devices, with everything else there is a parent that
> has several children.
>
> You have a PCI bus that has several PCI devices, one of them happens
> to be a IDE host controller with 2 channels connected to it. The other
> is your SuperIO chip with 2 GPIO pins and something else, and another
> SuperIO chip with 3 GIPO pins. Let's say you 1st chip monitors
> temperature in the case and the second interfaces wth some custom
> equipment measuring some thersholds in some chemical process. Are you
> saying that all 5 GPIO pins should be presented as one logical device
> that provides 5 outputs not related to each other? No, you have 5
> distinct devices with similar interfaces providing 5 distinct reads.
> Userspace may chose to group them somehow, based on external
> information that kernel does not have, but that's it. Kernel only
> provides uniform interface.
>
Each superio chip has the same logical devices inside.
With your approach we will have following schema:
bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb
superio2 - voltage, temp, gpio, rtc, wdt, acb
superio3 - voltage, temp, gpio, rtc, wdt, acb
superio4 - voltage, temp, gpio, rtc, wdt, acb
Each logical device driver (for existing superio schema)
is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 +
4*superio_chip_driver_size bytes
of the code.
With my - only 150*6 + 4*superio_chip_driver_size.
And not the code size is matter, but that fact, that changing one driver
(for example add feature to more precise temperature conversation) will
end up fixing huge amount of driver, but not the one file.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> Each superio chip has the same logical devices inside.
> With your approach we will have following schema:
>
> bus:
> superio1 - voltage, temp, gpio, rtc, wdt, acb
> superio2 - voltage, temp, gpio, rtc, wdt, acb
> superio3 - voltage, temp, gpio, rtc, wdt, acb
> superio4 - voltage, temp, gpio, rtc, wdt, acb
>
> Each logical device driver (for existing superio schema)
> is about(more than) 150 lines of code.
> With your approach above example will be 150*6*4 +
> 4*superio_chip_driver_size bytes
> of the code.
????? Let's count again, shall we? Suppose we have:
> superio1 - voltage, temp, gpio, rtc, wdt, acb
> superio2 - voltage, temp, gpio, rtc, wdt, acb
superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
or whatever. So here, you have 2 drivers to manage chips. Plus you
have 6 superio interface drivers - gpio, acb, etc...
It is exactly the same as your cheme size-wise.
There is no need to many-to-many relationship. Each chip is bound to
only one chip driver which registers several interfaces. Each
interface is bound to only one interface driver. Interface driver is
not chip specific, it knows how to run a specific interface (gpio,
temp) and relies on chip driver to properly manage access to the
hardware. Each combination of inetrface + interface driver produce one
class_device (call it sio, serio, whatever). Class device provides
unified view of the interface to the userspace.
What am I missing?
--
Dmitry
On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> <[email protected]> wrote:
>
> > Each superio chip has the same logical devices inside.
> > With your approach we will have following schema:
> >
> > bus:
> > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > superio4 - voltage, temp, gpio, rtc, wdt, acb
> >
> > Each logical device driver (for existing superio schema)
> > is about(more than) 150 lines of code.
> > With your approach above example will be 150*6*4 +
> > 4*superio_chip_driver_size bytes
> > of the code.
>
> ????? Let's count again, shall we? Suppose we have:
> > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > superio2 - voltage, temp, gpio, rtc, wdt, acb
> superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> or whatever. So here, you have 2 drivers to manage chips. Plus you
> have 6 superio interface drivers - gpio, acb, etc...
> It is exactly the same as your cheme size-wise.
>
> There is no need to many-to-many relationship. Each chip is bound to
> only one chip driver which registers several interfaces. Each
> interface is bound to only one interface driver. Interface driver is
> not chip specific, it knows how to run a specific interface (gpio,
> temp) and relies on chip driver to properly manage access to the
> hardware. Each combination of inetrface + interface driver produce one
> class_device (call it sio, serio, whatever). Class device provides
> unified view of the interface to the userspace.
>
> What am I missing?
Since each logical device does not know who use it, it can not be,
for example, removed optimally.
You need to run through whole superio device set to find those one that
has reference to logical device being removed.
And situation become much worse, when we have so called logical device
clones -
it is virtual logical device that emulates standard one, but inside
performs
in a different way. Clone creates inside superio device(for example such
device
can live at different address).
When you do not have ldev->sc relation, you must traverse through each
logical device
in each superio chip to find clones.
Thus you will need to traverse through each superio chip,
then through each logical device it references, just to remove one
logical device.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Wed, 2005-01-26 at 15:34 +0100, Jean Delvare wrote:
> Hi Evgeniy,
>
> > I presented the code.
> > Several times in special mail list.
>
> That's true. Except that the second time (at least) you didn't find
> anyone to review it. Also note that your patches are about superio, gpio
> and now access bus. The list is dedicated to hardware monitoring. This
> is no exact match, although it happens that some superio chips include
> hardware monitoring logical devices. So I reviewed the part I think I
> could help with, and skipped the rest (and I did tell the you, and the
> list, that I had).
It is the most closest to the superio subsystem mail list,
and all comments presented there about superio code were always right
and
indeed usefull.
I believe I addressed them all(except function prefixes :) )
> > Only problem that it was not sent to lkml, where there are
> > too many noise and flood. That is why while digging through it several
> > years ago I decided to drop this mail list.
>
> I agree that there is a heavy traffic on LKML - I am not subscribed
> myself just because of that. However, when one introduces a completely
> new subsystem, it definitely needs review by folks that have way more
> knowledge about the kernel internals than I do - expecially about the
> (bus) driver model.
A bit offtopic: the reason why we have such long discussion about
superio
is not that it is new, and you can see it if you dig the archive from
the
beginning.
> > I do not understand you, what are you trying to say? Waht is wrong?
> > I wrote the code.
> > I presented it.
> > I presented it again.
> > I presented it yeat another again.
> >
> > First time people answered, then - not.
>
> OK, blame me for having a day job, a girlfriend and a family. Blame me
> for not having the necessary time and knowledge to review your code.
:) You misunderstand me, sorry.
I absolutely did not want to blame anyone and
even did not have it in my thoughts :)
> And then think about it again. Maybe you did not present it to the right
> person(s). Maybe you did not present it in the correct form. Maybe you
> didn't properly explain what problem you were trying to solve - and
> failed to catch people's attention because of that. And maybe you
> should not have ignored some of my comments - and others'. I would
> invite you to read your own recent posts to the LKML again. Most
> objections you have received about your code - some of which were so
> blantantly valid (several drivers with the same name is fine, no
> kidding) - you first denied that there were any problem, then grumbled,
> then accepted to change but just not to make any trouble - not because
> you were wrong. You are not going anywhere here with this attitude.
<not personal to you reasonings...>
Most objections are so small, that is can not be called problems.
I will fix it soon.
And I still do not see any problems there, I just do not want to spend
my time in such meaningless dispute about module names.
I'm not religious fanatic which will with foam at the mouth try to
make it's word latest.
I prefer to do interesting things and it is much easier to change the
module
name than try to convince army of opponents :)
Superio design as actually another isssue, although I still do not
understand
why break well written working code just to what?
As I said, talk is cheap, if only discuss design notes, nothing can be
created.
</not personal to you reasonings...>
> Sure, we, kernel developers as a whole, lack time to properly review all
> the code that is sent to us. Even me, and I probably receive one
> hundredth of what Greg, Andrew or Linus receive. And now what? That's
> the way it is and we (and you) have to live with it. If you want the
> situation to improve, you can volunteer to review some code. Andrew's
> broken-out directories and LKML are full of patches that need review. Or
> pick one subsystem and track the patches applied to it. Really, do not
> hesitate to help. You certainly will learn much about kernel code review
> by doing so, and your own submissions are likely to be significantly
> better thanks to that. My story exactly.
And do I blame anyone?
Did I said that all you are fscking monsters that do not like my baby?
No, I presented the code and appreciate anyone's comments.
Thank you.
> > I ask for inclusion. It is included, and ohh now people recall,
> > that they wanted to complain.
>
> What other choice do they have at this point? Ignore or complain. I
> definitely prefer them to complain if they have a reason to - and the
> same would apply if it was my code and not yours.
I do not say it to your personally, but in general:
Let's discuss the code, let's discuss the design, but do not try to
say,
that code is bad just because one never see it before and it was just
appeared here, and one do not understand something...
Most of the thread is not discussion...
> Note that I don't blame Greg for pushing the code into Andrew's tree.
> This is what this tree is for, and now your patches got some exposure
> and you have objections to work on, to say the least. I also admit that
> some people here are being a little harsh, but I believe that each one
> of us is doing his/her best to improve the kernel. It just happens that
> our best isn't always as good as one would want.
>
> > Ok, I want to listen what technical problems do you see?
>
> As I explained before, I would like to see your superio subsystem
> integrate properly with existing drivers that need it before you attempt
> to add more functions on top of it. And I want a full documentation of
> your superio subsystem to be part of the patchset. It seems that most
> people here didn't get what you were doing and why you were doing it
> (at least I wasn't alone ;)), so obviously a complete documentation
> would be more than welcome - needed would in fact be the appropriate
> term.
Sure, I definitely will devote much time to document all pieces.
>
> > Jean, it looks like you forget how superio is designed.
> > Your pc87360 driver is all in one big piese of code, superio
> > is splitted into absolutely separated modules - _one_ for superio chip,
> > and _several_ for logical devices.
> >
> > I need to split your driver into at least 5 parts - pc8736x
> > initialisation(superio has it), i2c part(should be removed from superio
> > code), fan logical device(separate part), voltage monitor logical device
> > (separate part) and temperature monitor logical device (separate part).
>
> The whole thing is a single driver because it achieves one goal. The fact
> that National Semiconductor decided to use three different logical
> devices for temperatures, voltages and fans is an implementation detail.
> This alone doesn't justify a split of the source code. The "superio
> chip" part is what you have been working on and I agree it was needed.
> And I agree that the superio access has to be moved from my pc87360
> driver (and other similar drivers) to your superio driver.
>
> You do not *have* to separate all the parts. One single driver can
> request several logical devices, and this is precisely what I want us to
> do here. I agree that it could make sense to separate the logical
> devices on a per device (and driver) basis, if it allows us to reuse the
> code more easily. It is however not a requirement, that I can see.
I mean above that we need to separate them logically from superio
access
and i2c part.
But it is really better to have each logical device driver be a separate
module,
it is just easier to search and handle.
> > They are just separate modules, it is design feature to use _the_ _same_,
> > for example, voltage monitor module with _any_ number of existent superio
> > chips.
>
> It isn't the first time you say that, and I have to say I don't much
> get where you want to go. The hardware monitoring logical devices are
> completely different between PC8736x, IT87xxF, W836x7(T)HF and 47M1xx
> superio devices, just like the various other hardware monitoring chips
> are different. There is no code to be shared here, so nothing is
> duplicated.
>
> Maybe it is different with gpio or access bus? Is there some standard
> register organization among the various chip makers? I don't know
> these, so I cannot tell.
As I saw from different documentation - logical devices itself are the
same.
And it is the same for superio standard.
For example sc1100 and pc87366 superio chips have the same logical
inside,
although different logical device set.
> > And that will end up having tons of duplicated code in each driver:
> > temp monitor in A, temp monitor in B and so on...
> > volt monitor in A, volt monitor in B and so on...
>
> There is no logical device-based duplicated code in the superio hardware
> monitoring drivers at the moment, unless you see things I do not (if you
> do please let me know). The only thing that is duplicated accross the
> drivers is the superio accesses, agreed, and I am glad that your unified
> superio driver will put an end to this.
Not only access.
Logic inside superio chip is submitted to superio standard.
I designed(at least tried to) superio subsistem
that it can handle all differencies using per device callbacks.
> > Jean, we already discussed it a bit in lm_sensors mail list AFAR...
>
> Yes, 5 months ago, and we did not exactly agree. And we obviously still
> do not agree.
>
> Don't get me wrong, I am not saying that I don't want your code in the
> kernel. I am actually interested in it (the base superio part, in fact).
> All I am asking for is that you put some efforts in presenting your code
> correctly, splitting it the way it has to be, and getting it into the
> kernel step by step. You are not going to get any support from me by
> pretending that the superio hardware monitoring drivers need a full
> rewrite to accomodate with your unified superio driver - because I know
> it cannot be true. If you can provide a first patchset with core superio
> driver, documentation of it, and *minimum* updates of the pc87360 driver
> to make use of it, you can be sure I will review it with great care.
I definitely will do it.
Just get me time :)
Thank you.
> Thanks,
> --
> Jean Delvare
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > <[email protected]> wrote:
> >
> > > Each superio chip has the same logical devices inside.
> > > With your approach we will have following schema:
> > >
> > > bus:
> > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > >
> > > Each logical device driver (for existing superio schema)
> > > is about(more than) 150 lines of code.
> > > With your approach above example will be 150*6*4 +
> > > 4*superio_chip_driver_size bytes
> > > of the code.
> >
> > ????? Let's count again, shall we? Suppose we have:
> > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > have 6 superio interface drivers - gpio, acb, etc...
> > It is exactly the same as your cheme size-wise.
> >
> > There is no need to many-to-many relationship. Each chip is bound to
> > only one chip driver which registers several interfaces. Each
> > interface is bound to only one interface driver. Interface driver is
> > not chip specific, it knows how to run a specific interface (gpio,
> > temp) and relies on chip driver to properly manage access to the
> > hardware. Each combination of inetrface + interface driver produce one
> > class_device (call it sio, serio, whatever). Class device provides
> > unified view of the interface to the userspace.
> >
> > What am I missing?
>
> Since each logical device does not know who use it, it can not be,
> for example, removed optimally.
> You need to run through whole superio device set to find those one that
> has reference to logical device being removed.
What do you mean by removing optimally? Consider teher 2 scenarios:
- you unload logical device driver which knows all the logical
devices (interfaces) it is bound to and it releases those devices.
- you unload chip driver which knows what logical devices it has
registered and removes them. Logical devices in turn unbind themselves
from the logical drivers thay are bound to (only one for each device
and they have link).
Seems pretty clean to me.
> And situation become much worse, when we have so called logical device
> clones -
> it is virtual logical device that emulates standard one, but inside
> performs
> in a different way. Clone creates inside superio device(for example such
> device
> can live at different address).
> When you do not have ldev->sc relation, you must traverse through each
> logical device
> in each superio chip to find clones.
> Thus you will need to traverse through each superio chip,
> then through each logical device it references, just to remove one
> logical device.
I am confused and need a concrete example. I would think that cases
such as these should not require eny special handling, hardware access
should be hidden from logical drivers by the chip driver. Or if only
difference is the port address then it probably should be set by the
chip driver as attribute of logical device.
Look at the serio system again. psmouse module knows how to talk to
i8042-type ports. It does not rellay matter to it whther the port is
on actual i8042 controller or somewhere else. What matters that it is
PS/2 port and it supports writes and reads and that is it. How exactly
read is performed (what port address, locking, etc) is of no concern
to psmouse. The same I think should be happening here.
--
Dmitry
On Wed, 2005-01-26 at 09:00 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 13:59:17 +0300, Evgeniy Polyakov
> <[email protected]> wrote:
> > On Wed, 2005-01-26 at 10:14 +0000, Christoph Hellwig wrote:
> > > On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > > > I have one rule - if noone answers that it means noone objects,
> > > > or it is not interesting for anyone, and thus noone objects.
> > >
> > > That's simply not true. The amount of patches submitted is extremly
> > > huge and the reviewers don't have time to look at everythning.
> > >
> > > If no one replies it simply means no one has looked at it in enough
> > > detail to comment yet.
> >
> > That is why I resent it several times.
> > Then I asked for inclusion.
> >
> > I never send it to lkml just because simple static/non static + module
> > name
> > discussion in lkml already overflowed into more than 20 messages...
>
> Well, not everyone is subscribed to lm_sensors mailing list but
> nonetheless are interested when a new subsystem is introduced into the
> kernel. There several established subsystems (network, USB, ide) whose
> maintainers people trust either because of the good track record or
> because it affects small number of people so the main discussion is
> kept on special lists. But even then most patches are presented on
> LKML when issues ironed out on special list.
>
> With a new subsystem it is wise to present it to LKML so it gets wider coverage.
>
Khm-khm, if we will always wait untill everyone will comment the code or
even initial
design, then nothing will be created at all.
Btw, where was comments about w1, kernel connector and acrypto?
They were presented several times in lkml and all are completely new
subsystems.
Should I stop developing just because I did not get comments?
Above discussion was not borned because it is new subsystem, btw...
Ok, I want to thank everyone for discussion.
I believe that new subsystem must be discussed in specific mail lists
before
it goes mainstream, but not necessarily in lkml.
But if it really changes a lot of things, then of course it should be
presented
in lkml.
Thank you.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> <[email protected]> wrote:
> > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > <[email protected]> wrote:
> > >
> > > > Each superio chip has the same logical devices inside.
> > > > With your approach we will have following schema:
> > > >
> > > > bus:
> > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > >
> > > > Each logical device driver (for existing superio schema)
> > > > is about(more than) 150 lines of code.
> > > > With your approach above example will be 150*6*4 +
> > > > 4*superio_chip_driver_size bytes
> > > > of the code.
> > >
> > > ????? Let's count again, shall we? Suppose we have:
> > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > have 6 superio interface drivers - gpio, acb, etc...
> > > It is exactly the same as your cheme size-wise.
> > >
> > > There is no need to many-to-many relationship. Each chip is bound to
> > > only one chip driver which registers several interfaces. Each
> > > interface is bound to only one interface driver. Interface driver is
> > > not chip specific, it knows how to run a specific interface (gpio,
> > > temp) and relies on chip driver to properly manage access to the
> > > hardware. Each combination of inetrface + interface driver produce one
> > > class_device (call it sio, serio, whatever). Class device provides
> > > unified view of the interface to the userspace.
> > >
> > > What am I missing?
> >
> > Since each logical device does not know who use it, it can not be,
> > for example, removed optimally.
> > You need to run through whole superio device set to find those one that
> > has reference to logical device being removed.
>
> What do you mean by removing optimally? Consider teher 2 scenarios:
> - you unload logical device driver which knows all the logical
> devices (interfaces) it is bound to and it releases those devices.
It does not know chip drivers, which reference it.
We need to scan all superio chips to find that.
> - you unload chip driver which knows what logical devices it has
> registered and removes them. Logical devices in turn unbind themselves
> from the logical drivers thay are bound to (only one for each device
> and they have link).
> Seems pretty clean to me.
Yes, since there is sc->ldev relation.
> > And situation become much worse, when we have so called logical device
> > clones -
> > it is virtual logical device that emulates standard one, but inside
> > performs
> > in a different way. Clone creates inside superio device(for example such
> > device
> > can live at different address).
> > When you do not have ldev->sc relation, you must traverse through each
> > logical device
> > in each superio chip to find clones.
> > Thus you will need to traverse through each superio chip,
> > then through each logical device it references, just to remove one
> > logical device.
>
> I am confused and need a concrete example. I would think that cases
> such as these should not require eny special handling, hardware access
> should be hidden from logical drivers by the chip driver. Or if only
> difference is the port address then it probably should be set by the
> chip driver as attribute of logical device.
Consider sc.c and GPIO logical device in SC1100 (scx driver).
/*
* SuperIO core is registering logical device.
* SuperIO chip knows where it must live.
* If logical device being registered lives at the different location
* (for example when it was registered for all devices,
* but has address(index) corresponding to only one SuperIO chip)
* then we will register new logical device with the same name
* but with the different location(index).
*
* It is called clone.
*/
> Look at the serio system again. psmouse module knows how to talk to
> i8042-type ports. It does not rellay matter to it whther the port is
> on actual i8042 controller or somewhere else. What matters that it is
> PS/2 port and it supports writes and reads and that is it. How exactly
> read is performed (what port address, locking, etc) is of no concern
> to psmouse. The same I think should be happening here.
psmouse and sport are completely different example.
Consider you have mouse, that is shared between several users.
Should it have reference to each user?
Consider directory that is bind-mounted, should it have reference to
it's
original parent tree?
Consider page, that must be swapped, should it have access to all
processes
that share it?
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > <[email protected]> wrote:
> > > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > > <[email protected]> wrote:
> > > >
> > > > > Each superio chip has the same logical devices inside.
> > > > > With your approach we will have following schema:
> > > > >
> > > > > bus:
> > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > > >
> > > > > Each logical device driver (for existing superio schema)
> > > > > is about(more than) 150 lines of code.
> > > > > With your approach above example will be 150*6*4 +
> > > > > 4*superio_chip_driver_size bytes
> > > > > of the code.
> > > >
> > > > ????? Let's count again, shall we? Suppose we have:
> > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > > have 6 superio interface drivers - gpio, acb, etc...
> > > > It is exactly the same as your cheme size-wise.
> > > >
> > > > There is no need to many-to-many relationship. Each chip is bound to
> > > > only one chip driver which registers several interfaces. Each
> > > > interface is bound to only one interface driver. Interface driver is
> > > > not chip specific, it knows how to run a specific interface (gpio,
> > > > temp) and relies on chip driver to properly manage access to the
> > > > hardware. Each combination of inetrface + interface driver produce one
> > > > class_device (call it sio, serio, whatever). Class device provides
> > > > unified view of the interface to the userspace.
> > > >
> > > > What am I missing?
> > >
> > > Since each logical device does not know who use it, it can not be,
> > > for example, removed optimally.
> > > You need to run through whole superio device set to find those one that
> > > has reference to logical device being removed.
> >
> > What do you mean by removing optimally? Consider teher 2 scenarios:
> > - you unload logical device driver which knows all the logical
> > devices (interfaces) it is bound to and it releases those devices.
>
> It does not know chip drivers, which reference it.
Of course it does, every logical device has one parent. Individual
GPIO pins are not spread across your motherboard. Every one of them
lives on some chip. They can all be driven by the same driver but they
are different devices. It is like all your IDE drives are driven by
the same driver but (unless LVM which is diffrent layer comes to play)
they are still different drives.
> We need to scan all superio chips to find that.
>
> > - you unload chip driver which knows what logical devices it has
> > registered and removes them. Logical devices in turn unbind themselves
> > from the logical drivers thay are bound to (only one for each device
> > and they have link).
> > Seems pretty clean to me.
>
> Yes, since there is sc->ldev relation.
>
> > > And situation become much worse, when we have so called logical device
> > > clones -
> > > it is virtual logical device that emulates standard one, but inside
> > > performs
> > > in a different way. Clone creates inside superio device(for example such
> > > device
> > > can live at different address).
> > > When you do not have ldev->sc relation, you must traverse through each
> > > logical device
> > > in each superio chip to find clones.
> > > Thus you will need to traverse through each superio chip,
> > > then through each logical device it references, just to remove one
> > > logical device.
> >
> > I am confused and need a concrete example. I would think that cases
> > such as these should not require eny special handling, hardware access
> > should be hidden from logical drivers by the chip driver. Or if only
> > difference is the port address then it probably should be set by the
> > chip driver as attribute of logical device.
>
> Consider sc.c and GPIO logical device in SC1100 (scx driver).
>
> /*
> * SuperIO core is registering logical device.
> * SuperIO chip knows where it must live.
> * If logical device being registered lives at the different location
> * (for example when it was registered for all devices,
> * but has address(index) corresponding to only one SuperIO chip)
> * then we will register new logical device with the same name
> * but with the different location(index).
> *
> * It is called clone.
> */
>
In this sense every device is a clone. Consider I have 2 EtherExpress
cards in my box. They surely live at different addresses but PCI
system does not mess with "clones". And network layer does not care
whether both of them driven by e100 or one is e100 and the other is
RTL.
--
Dmitry
On Wed, Jan 26, 2005 at 07:38:48PM +0300, Evgeniy Polyakov wrote:
>...
> Btw, where was comments about w1, kernel connector and acrypto?
> They were presented several times in lkml and all are completely new
> subsystems.
> Should I stop developing just because I did not get comments?
>...
I sent you comments regarding w1 two months ago regarding:
- the unneeded dscore -> ds9490r rename in the Makefile
- completely unused EXPORT_SYMBOL's (that seem to be still unused today)
Being honest, I have to admit that your reactions didn't sound as if you
were waiting for comments.
> Thank you.
>
> Evgeniy Polyakov
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Jan 26, 2005 at 01:59:17PM +0300, Evgeniy Polyakov wrote:
> On Wed, 2005-01-26 at 10:14 +0000, Christoph Hellwig wrote:
> > On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > > I have one rule - if noone answers that it means noone objects,
> > > or it is not interesting for anyone, and thus noone objects.
> >
> > That's simply not true. The amount of patches submitted is extremly
> > huge and the reviewers don't have time to look at everythning.
> >
> > If no one replies it simply means no one has looked at it in enough
> > detail to comment yet.
>
> That is why I resent it several times.
> Then I asked for inclusion.
>
> I never send it to lkml just because simple static/non static + module
> name
> discussion in lkml already overflowed into more than 20 messages...
Your opinion on some things are different than the opinions of other
people on some issues. That's normal.
Then a discussion arises.
That's normal and part of a review of some code.
E.g. the "module name discussion" covered a real problem.
Be it 1 email or be it 100 emails - the main point is simply that all
code in the kernel should be as good as possible and as near as possible
to kernel standards.
The Linux kernel is a big project with _many_ people involved.
I've also had people telling me that this or that I sent in a patch was
nonsense. That's normal (and a criticism of your code is not meant as a
personal insult) and leads to better code in the kernel.
> Evgeniy Polyakov
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, 26 Jan 2005 13:26:38 -0500
Dmitry Torokhov <[email protected]> wrote:
> > > > > > Since each logical device does not know who use it, it can not be,
> > > > > > for example, removed optimally.
> > > > > > You need to run through whole superio device set to find those one that
> > > > > > has reference to logical device being removed.
> > > > >
> > > > > What do you mean by removing optimally? Consider teher 2 scenarios:
> > > > > - you unload logical device driver which knows all the logical
> > > > > devices (interfaces) it is bound to and it releases those devices.
> > > >
> > > > It does not know chip drivers, which reference it.
> > >
> > > Of course it does, every logical device has one parent. Individual
> > > GPIO pins are not spread across your motherboard. Every one of them
> > > lives on some chip. They can all be driven by the same driver but they
> > > are different devices. It is like all your IDE drives are driven by
> > > the same driver but (unless LVM which is diffrent layer comes to play)
> > > they are still different drives.
> >
> > No, there is no "parent".
> > Each logical device is "shared" between several superio chips.
> > It is presented design.
>
> Ok, I presume that userspace although you saying that logical device
> is "shared" between chips different GPIO pins still visible to
> userspace as separate entities (correct me if I am wrong). That means
> that you chose in your implementation not to abstract out individual
> parts of SuperIO container as individual devices and instead have
> several logical drivers bound directly to a same chip. And that is why
> you need n-m relationship and inability to fit to the driver model and
> potential issues with power management. Instead of this
Userspace has access to GPIO logical device by it's name
and name of the superio chip it is connected to.
> / <ldev>
> <base-dev (PCI|ISA|other)> - <sdev> - <ldev>
> \ <ldev>
>
> you need this
>
> /<sdev> - <ldev>
> <base-dev (PCI|ISA|other)> - <sdev> - <ldev>
> \ <sdev> - <ldev>
>
> This will decouple chip drivers from the logical drivers.
>
> I argue that present design is sub-optimal and will hurt in the long run.
This picture is somewhat better presents superio design:
sdev sdev
|-----| |-----|
ldev ldev ldev
Where |---| links are bidirectional.
Probably you are right, but I doubt :)
> > > > We need to scan all superio chips to find that.
> > > >
> > > > > - you unload chip driver which knows what logical devices it has
> > > > > registered and removes them. Logical devices in turn unbind themselves
> > > > > from the logical drivers thay are bound to (only one for each device
> > > > > and they have link).
> > > > > Seems pretty clean to me.
> > > >
> > > > Yes, since there is sc->ldev relation.
> > > >
> > > > > > And situation become much worse, when we have so called logical device
> > > > > > clones -
> > > > > > it is virtual logical device that emulates standard one, but inside
> > > > > > performs
> > > > > > in a different way. Clone creates inside superio device(for example such
> > > > > > device
> > > > > > can live at different address).
> > > > > > When you do not have ldev->sc relation, you must traverse through each
> > > > > > logical device
> > > > > > in each superio chip to find clones.
> > > > > > Thus you will need to traverse through each superio chip,
> > > > > > then through each logical device it references, just to remove one
> > > > > > logical device.
> > > > >
> > > > > I am confused and need a concrete example. I would think that cases
> > > > > such as these should not require eny special handling, hardware access
> > > > > should be hidden from logical drivers by the chip driver. Or if only
> > > > > difference is the port address then it probably should be set by the
> > > > > chip driver as attribute of logical device.
> > > >
> > > > Consider sc.c and GPIO logical device in SC1100 (scx driver).
> > > >
> > > > /*
> > > > * SuperIO core is registering logical device.
> > > > * SuperIO chip knows where it must live.
> > > > * If logical device being registered lives at the different location
> > > > * (for example when it was registered for all devices,
> > > > * but has address(index) corresponding to only one SuperIO chip)
> > > > * then we will register new logical device with the same name
> > > > * but with the different location(index).
> > > > *
> > > > * It is called clone.
> > > > */
> > > >
> > >
> > > In this sense every device is a clone. Consider I have 2 EtherExpress
> > > cards in my box. They surely live at different addresses but PCI
> > > system does not mess with "clones". And network layer does not care
> > > whether both of them driven by e100 or one is e100 and the other is
> > > RTL.
> >
> > It is not the same as two different devices on the bus.
> >
> > Consider sc1100 - GPIO lives in PCI aperture, absolutely not where
> > superio lives.
> > (And it is actully not logical device in this case, but it fits well
> > into design).
>
> It does not matter where it "lives". The chip driver should not expose
> these details to interface driver. Although you said serio examples
> are not applicable here let's take another look there: i8042 and
> pcips2 modules. One provides serio ports that live in legacy IO space,
> the other is PCI-based. psmouse would not care less which one is
> behind the port it is bound to.
Chip driver provides access methods to the attached logical devices.
It probes and activates them, if appropriate module is loaded.
Your example again is not suitable for superio case.
With superio you have several identical logical devices, access to which
is absolutely standard in second level(logic befind access),
but in first one(physicall access) it can differ.
So here is the real example of superio usage:
userspace
|
superio core
......
GPIO
|----| |--|
pc87366 sc1100
|----| |---|
WDT
Logical device GPIO is accessed by read/write methods, which only have
pin number(it is not how this methods are exactly implemeted though)
as parameter.
For example userspace accesses GPIO at sc1100 - it will be translated
into read methods called from appropriate superio chip with appropriate
parameters.
When we have multiple GPIO logical devices(each in it's own superio chip)
it is more convenient to use just the same object.
I did not understand you from the beginning...
It can be turned into device model quite well, only individual objects
should have backward references to allow easier manipulation with it's
"owners". Your above schema with device model is quite right, just add
invisible links from each device to/from it's "masters".
>
> --
> Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Wed, 26 Jan 2005 23:07:12 +0300, Evgeniy Polyakov
<[email protected]> wrote:
>
> Chip driver provides access methods to the attached logical devices.
> It probes and activates them, if appropriate module is loaded.
>
> Your example again is not suitable for superio case.
>
> With superio you have several identical logical devices, access to which
> is absolutely standard in second level(logic befind access),
> but in first one(physicall access) it can differ.
>
> So here is the real example of superio usage:
>
> userspace
> |
> superio core
> ......
>
> GPIO
> |----| |--|
> pc87366 sc1100
> |----| |---|
> WDT
>
> Logical device GPIO is accessed by read/write methods, which only have
> pin number(it is not how this methods are exactly implemeted though)
> as parameter.
>
> For example userspace accesses GPIO at sc1100 - it will be translated
> into read methods called from appropriate superio chip with appropriate
> parameters.
>
> When we have multiple GPIO logical devices(each in it's own superio chip)
> it is more convenient to use just the same object.
I take an exception to that. I think useroace is not concerned with
topology and ownership of logical devices, the data is more important.
I.e. you need to know that some pin respons to CPU temperature but you
don't really care that it connected to it87 as opposed to some other
chip. Therefore I think that ldev should translate to exactly the same
underlying object. Consider the picture below:
GPIO0 GPIO1 GPIO2 GPIO3
| | | |
pc87266 sc1100 blah123
| |
WDT0 WDT1
This will allow:
- map every hardware piece (not entire chip, separate functions) to a
device file to userspace can use standard read/write/select/poll if
choses so.
- easily represent them in sysfs and also allow userspace access to
individual bits through sysfs attributes.
- will not give headaches with poer management when half of device is
powered down and half is active.
- provided that there are alternative interfaces outlined above
superio can be decoupled from the connector.
I wonder if it should be called "gpio" bus as opposed to superio
because only chips are "super", the bus consists of very simple
devices and drivers.
> I did not understand you from the beginning...
We are getting there I believe ;)
--
Dmitry
On Wed, 26 Jan 2005 20:20:27 +0100
Jean Delvare <[email protected]> wrote:
> [Voluntarily skipping a large part of the discussion so as to stop
> wasting everyone's time and focus on the one technical point I am
> interested in.]
>
> Hi Evgeniy,
>
> > As I saw from different documentation - logical devices itself are the
> > same.
> >
> > And it is the same for superio standard.
> >
> > For example sc1100 and pc87366 superio chips have the same logical
> > inside, although different logical device set.
> >
> > (...)
> >
> > Not only access.
> > Logic inside superio chip is submitted to superio standard.
> > I designed(at least tried to) superio subsistem
> > that it can handle all differencies using per device callbacks.
>
> I would like to ensure that we agree on what is common to all Super-I/O
> chips (as per Intel's LPC specification).
>
> 1* Super-I/O are accessed at I/O addresses 0x2e+0x2f or alternate
> addresses 0x4e+0x4f.
>
> 2* These addresses give access to a 256 byte addressing space.
>
> 3* Super-I/O chips are divided in logical devices, which can be selected
> by writing its id to 0x07. What each logical device does is not
> standardized (depends of the chip).
>
> 4* Range 0x00-0x2f is common to all logical devices, while range
> 0x30-0xff is logical-device specific.
>
> 5* Range 0x20-0x2f contains chip-wide identification and configuration
> registers. Definition of these registers is not standardized.
>
> 6* 0x31 controls the activation of each logical device, 0x60-0x63 its
> base address, 0x70-0x73 its interrupts. Definition of these registers is
> standardized.
>
> 7* Range 0xf0-0xff contains logical device-specific configuration
> registers. Definition of these registers is not standardized.
>
> And that's about it. The way each logical device works (how registers
> are mapped from the base address) is completely chip-specific.
>
> Do we agree on all this, or did I miss somthing? I would like to make
> sure that, when you refer to sharing as much code as possible between
> the various Super-I/O chips, you really mean the organization of logical
> devices within the Super-I/O (selection, retrieval of base address and
> interrupt configuration) and not the logical devices themselves.
You are absolutely right, I just want to add following note:
Most of the logical devices inside superio chips has standardized access methods.
One just need base address and index, that is all.
For such devices all infrastructure already exists in the provided superio core.
One just need to provide one logical device driver for it(like sc_gpio.c).
But, sometimes it really can be the situation, when logical device is not
obeyed to rules in the existing logical device driver(like GPIO in sc1100, which is
not superio logical device but is fitted design quite well), for such
cases there is also infrastructure in superio driver. For example scx.c -
it has it's own private GPIO logical device, which is "cloned" from the
"standard"(described in sc_gpio.c) logical device(clones actully have
almost nothing in common).
Situation with device cloning is very unlikely according to various superio
chips I saw and read datasheets.
> Thanks,
> --
> Jean Delvare
> http://khali.linux-fr.org/
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Wed, Jan 26, 2005 at 01:12:34PM +0000, Russell King wrote:
> On Wed, Jan 26, 2005 at 10:14:34AM +0000, Christoph Hellwig wrote:
> > That's simply not true. The amount of patches submitted is extremly
> > huge and the reviewers don't have time to look at everythning.
> >
> > If no one replies it simply means no one has looked at it in enough
> > detail to comment yet.
>
> How do people get to know this? Grape vines and crystal balls are
> inherently unreliable.
If someone had looked and considered it good he'd have replied and
said that. Simple ACK/NACK scheme - if neither returns consider it
lost.
> So, if the community has a problem with enough time to review patches,
> the community must get more (good) patch reviewers. We can't go around
> blaming the patch submitters for a community failing.
Absolutely. I think the major problem is that no one pays people for
doing reviews so this is purely a spare-time job. And that spare time
is limited due to real life issues for most people.
[Voluntarily skipping a large part of the discussion so as to stop
wasting everyone's time and focus on the one technical point I am
interested in.]
Hi Evgeniy,
> As I saw from different documentation - logical devices itself are the
> same.
>
> And it is the same for superio standard.
>
> For example sc1100 and pc87366 superio chips have the same logical
> inside, although different logical device set.
>
> (...)
>
> Not only access.
> Logic inside superio chip is submitted to superio standard.
> I designed(at least tried to) superio subsistem
> that it can handle all differencies using per device callbacks.
I would like to ensure that we agree on what is common to all Super-I/O
chips (as per Intel's LPC specification).
1* Super-I/O are accessed at I/O addresses 0x2e+0x2f or alternate
addresses 0x4e+0x4f.
2* These addresses give access to a 256 byte addressing space.
3* Super-I/O chips are divided in logical devices, which can be selected
by writing its id to 0x07. What each logical device does is not
standardized (depends of the chip).
4* Range 0x00-0x2f is common to all logical devices, while range
0x30-0xff is logical-device specific.
5* Range 0x20-0x2f contains chip-wide identification and configuration
registers. Definition of these registers is not standardized.
6* 0x31 controls the activation of each logical device, 0x60-0x63 its
base address, 0x70-0x73 its interrupts. Definition of these registers is
standardized.
7* Range 0xf0-0xff contains logical device-specific configuration
registers. Definition of these registers is not standardized.
And that's about it. The way each logical device works (how registers
are mapped from the base address) is completely chip-specific.
Do we agree on all this, or did I miss somthing? I would like to make
sure that, when you refer to sharing as much code as possible between
the various Super-I/O chips, you really mean the organization of logical
devices within the Super-I/O (selection, retrieval of base address and
interrupt configuration) and not the logical devices themselves.
Thanks,
--
Jean Delvare
http://khali.linux-fr.org/
On Wed, 26 Jan 2005 19:19:41 +0100
Adrian Bunk <[email protected]> wrote:
> On Wed, Jan 26, 2005 at 07:38:48PM +0300, Evgeniy Polyakov wrote:
> >...
> > Btw, where was comments about w1, kernel connector and acrypto?
> > They were presented several times in lkml and all are completely new
> > subsystems.
> > Should I stop developing just because I did not get comments?
> >...
>
> I sent you comments regarding w1 two months ago regarding:
> - the unneeded dscore -> ds9490r rename in the Makefile
> - completely unused EXPORT_SYMBOL's (that seem to be still unused today)
>
> Being honest, I have to admit that your reactions didn't sound as if you
> were waiting for comments.
>
> > Thank you.
I greatly appreciate your comments, and they were addressed.
Part of exported symbols are unexported, patch is just waiting to be sent,
but I do not agree with dscore rename. I just do not understand it's advantage.
> cu
> Adrian
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Wed, 26 Jan 2005 20:39:36 +0300, Evgeniy Polyakov
<[email protected]> wrote:
> On Wed, 2005-01-26 at 11:55 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
> > <[email protected]> wrote:
> > > On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > > > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > > > <[email protected]> wrote:
> > > > > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > > > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > > > > <[email protected]> wrote:
> > > > > >
> > > > > > > Each superio chip has the same logical devices inside.
> > > > > > > With your approach we will have following schema:
> > > > > > >
> > > > > > > bus:
> > > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > >
> > > > > > > Each logical device driver (for existing superio schema)
> > > > > > > is about(more than) 150 lines of code.
> > > > > > > With your approach above example will be 150*6*4 +
> > > > > > > 4*superio_chip_driver_size bytes
> > > > > > > of the code.
> > > > > >
> > > > > > ????? Let's count again, shall we? Suppose we have:
> > > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > > > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > > > > have 6 superio interface drivers - gpio, acb, etc...
> > > > > > It is exactly the same as your cheme size-wise.
> > > > > >
> > > > > > There is no need to many-to-many relationship. Each chip is bound to
> > > > > > only one chip driver which registers several interfaces. Each
> > > > > > interface is bound to only one interface driver. Interface driver is
> > > > > > not chip specific, it knows how to run a specific interface (gpio,
> > > > > > temp) and relies on chip driver to properly manage access to the
> > > > > > hardware. Each combination of inetrface + interface driver produce one
> > > > > > class_device (call it sio, serio, whatever). Class device provides
> > > > > > unified view of the interface to the userspace.
> > > > > >
> > > > > > What am I missing?
> > > > >
> > > > > Since each logical device does not know who use it, it can not be,
> > > > > for example, removed optimally.
> > > > > You need to run through whole superio device set to find those one that
> > > > > has reference to logical device being removed.
> > > >
> > > > What do you mean by removing optimally? Consider teher 2 scenarios:
> > > > - you unload logical device driver which knows all the logical
> > > > devices (interfaces) it is bound to and it releases those devices.
> > >
> > > It does not know chip drivers, which reference it.
> >
> > Of course it does, every logical device has one parent. Individual
> > GPIO pins are not spread across your motherboard. Every one of them
> > lives on some chip. They can all be driven by the same driver but they
> > are different devices. It is like all your IDE drives are driven by
> > the same driver but (unless LVM which is diffrent layer comes to play)
> > they are still different drives.
>
> No, there is no "parent".
> Each logical device is "shared" between several superio chips.
> It is presented design.
Ok, I presume that userspace although you saying that logical device
is "shared" between chips different GPIO pins still visible to
userspace as separate entities (correct me if I am wrong). That means
that you chose in your implementation not to abstract out individual
parts of SuperIO container as individual devices and instead have
several logical drivers bound directly to a same chip. And that is why
you need n-m relationship and inability to fit to the driver model and
potential issues with power management. Instead of this
/ <ldev>
<base-dev (PCI|ISA|other)> - <sdev> - <ldev>
\ <ldev>
you need this
/<sdev> - <ldev>
<base-dev (PCI|ISA|other)> - <sdev> - <ldev>
\ <sdev> - <ldev>
This will decouple chip drivers from the logical drivers.
I argue that present design is sub-optimal and will hurt in the long run.
>
> > > We need to scan all superio chips to find that.
> > >
> > > > - you unload chip driver which knows what logical devices it has
> > > > registered and removes them. Logical devices in turn unbind themselves
> > > > from the logical drivers thay are bound to (only one for each device
> > > > and they have link).
> > > > Seems pretty clean to me.
> > >
> > > Yes, since there is sc->ldev relation.
> > >
> > > > > And situation become much worse, when we have so called logical device
> > > > > clones -
> > > > > it is virtual logical device that emulates standard one, but inside
> > > > > performs
> > > > > in a different way. Clone creates inside superio device(for example such
> > > > > device
> > > > > can live at different address).
> > > > > When you do not have ldev->sc relation, you must traverse through each
> > > > > logical device
> > > > > in each superio chip to find clones.
> > > > > Thus you will need to traverse through each superio chip,
> > > > > then through each logical device it references, just to remove one
> > > > > logical device.
> > > >
> > > > I am confused and need a concrete example. I would think that cases
> > > > such as these should not require eny special handling, hardware access
> > > > should be hidden from logical drivers by the chip driver. Or if only
> > > > difference is the port address then it probably should be set by the
> > > > chip driver as attribute of logical device.
> > >
> > > Consider sc.c and GPIO logical device in SC1100 (scx driver).
> > >
> > > /*
> > > * SuperIO core is registering logical device.
> > > * SuperIO chip knows where it must live.
> > > * If logical device being registered lives at the different location
> > > * (for example when it was registered for all devices,
> > > * but has address(index) corresponding to only one SuperIO chip)
> > > * then we will register new logical device with the same name
> > > * but with the different location(index).
> > > *
> > > * It is called clone.
> > > */
> > >
> >
> > In this sense every device is a clone. Consider I have 2 EtherExpress
> > cards in my box. They surely live at different addresses but PCI
> > system does not mess with "clones". And network layer does not care
> > whether both of them driven by e100 or one is e100 and the other is
> > RTL.
>
> It is not the same as two different devices on the bus.
>
> Consider sc1100 - GPIO lives in PCI aperture, absolutely not where
> superio lives.
> (And it is actully not logical device in this case, but it fits well
> into design).
It does not matter where it "lives". The chip driver should not expose
these details to interface driver. Although you said serio examples
are not applicable here let's take another look there: i8042 and
pcips2 modules. One provides serio ports that live in legacy IO space,
the other is PCI-based. psmouse would not care less which one is
behind the port it is bound to.
>
> You skipped my examples, but presented design is very convenient to the
> situation,
> when you have two different sets of devices, or classes of devices, each
> of which
> can have link to any device from the other set.
They were from different domains so irrelevant.
--
Dmitry
On Wed, 2005-01-26 at 11:55 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
> <[email protected]> wrote:
> > On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > > <[email protected]> wrote:
> > > > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > > > <[email protected]> wrote:
> > > > >
> > > > > > Each superio chip has the same logical devices inside.
> > > > > > With your approach we will have following schema:
> > > > > >
> > > > > > bus:
> > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > > > >
> > > > > > Each logical device driver (for existing superio schema)
> > > > > > is about(more than) 150 lines of code.
> > > > > > With your approach above example will be 150*6*4 +
> > > > > > 4*superio_chip_driver_size bytes
> > > > > > of the code.
> > > > >
> > > > > ????? Let's count again, shall we? Suppose we have:
> > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > > > have 6 superio interface drivers - gpio, acb, etc...
> > > > > It is exactly the same as your cheme size-wise.
> > > > >
> > > > > There is no need to many-to-many relationship. Each chip is bound to
> > > > > only one chip driver which registers several interfaces. Each
> > > > > interface is bound to only one interface driver. Interface driver is
> > > > > not chip specific, it knows how to run a specific interface (gpio,
> > > > > temp) and relies on chip driver to properly manage access to the
> > > > > hardware. Each combination of inetrface + interface driver produce one
> > > > > class_device (call it sio, serio, whatever). Class device provides
> > > > > unified view of the interface to the userspace.
> > > > >
> > > > > What am I missing?
> > > >
> > > > Since each logical device does not know who use it, it can not be,
> > > > for example, removed optimally.
> > > > You need to run through whole superio device set to find those one that
> > > > has reference to logical device being removed.
> > >
> > > What do you mean by removing optimally? Consider teher 2 scenarios:
> > > - you unload logical device driver which knows all the logical
> > > devices (interfaces) it is bound to and it releases those devices.
> >
> > It does not know chip drivers, which reference it.
>
> Of course it does, every logical device has one parent. Individual
> GPIO pins are not spread across your motherboard. Every one of them
> lives on some chip. They can all be driven by the same driver but they
> are different devices. It is like all your IDE drives are driven by
> the same driver but (unless LVM which is diffrent layer comes to play)
> they are still different drives.
No, there is no "parent".
Each logical device is "shared" between several superio chips.
It is presented design.
More below.
> > We need to scan all superio chips to find that.
> >
> > > - you unload chip driver which knows what logical devices it has
> > > registered and removes them. Logical devices in turn unbind themselves
> > > from the logical drivers thay are bound to (only one for each device
> > > and they have link).
> > > Seems pretty clean to me.
> >
> > Yes, since there is sc->ldev relation.
> >
> > > > And situation become much worse, when we have so called logical device
> > > > clones -
> > > > it is virtual logical device that emulates standard one, but inside
> > > > performs
> > > > in a different way. Clone creates inside superio device(for example such
> > > > device
> > > > can live at different address).
> > > > When you do not have ldev->sc relation, you must traverse through each
> > > > logical device
> > > > in each superio chip to find clones.
> > > > Thus you will need to traverse through each superio chip,
> > > > then through each logical device it references, just to remove one
> > > > logical device.
> > >
> > > I am confused and need a concrete example. I would think that cases
> > > such as these should not require eny special handling, hardware access
> > > should be hidden from logical drivers by the chip driver. Or if only
> > > difference is the port address then it probably should be set by the
> > > chip driver as attribute of logical device.
> >
> > Consider sc.c and GPIO logical device in SC1100 (scx driver).
> >
> > /*
> > * SuperIO core is registering logical device.
> > * SuperIO chip knows where it must live.
> > * If logical device being registered lives at the different location
> > * (for example when it was registered for all devices,
> > * but has address(index) corresponding to only one SuperIO chip)
> > * then we will register new logical device with the same name
> > * but with the different location(index).
> > *
> > * It is called clone.
> > */
> >
>
> In this sense every device is a clone. Consider I have 2 EtherExpress
> cards in my box. They surely live at different addresses but PCI
> system does not mess with "clones". And network layer does not care
> whether both of them driven by e100 or one is e100 and the other is
> RTL.
It is not the same as two different devices on the bus.
Consider sc1100 - GPIO lives in PCI aperture, absolutely not where
superio lives.
(And it is actully not logical device in this case, but it fits well
into design).
You skipped my examples, but presented design is very convenient to the
situation,
when you have two different sets of devices, or classes of devices, each
of which
can have link to any device from the other set.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
autofs has exploded far, far beyond complete nonfunctionality, where
in prior 2.6.x it was not quite so blatantly a doorstop preventing all
logins on the machine, and, in fact, multiuser mode altogether.
Whoever's responsible, prepare to be flamed to a crisp the likes of
which has never been witnessed before by observers of solar probes, nor
conceived of by the most visionary and imaginative of eschatologists.
-- wli
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>> - Lots of updates and fixes all over the place.
>> - On my test box there is no flashing cursor on the vga console. Known bug,
>> please don't report it.
>> Binary searching shows that the bug was introduced by
>> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
On Wed, Jan 26, 2005 at 10:18:57PM -0800, William Lee Irwin III wrote:
> autofs has exploded far, far beyond complete nonfunctionality, where
> in prior 2.6.x it was not quite so blatantly a doorstop preventing all
> logins on the machine, and, in fact, multiuser mode altogether.
> Whoever's responsible, prepare to be flamed to a crisp the likes of
> which has never been witnessed before by observers of solar probes, nor
> conceived of by the most visionary and imaginative of eschatologists.
Looks like I just need to smack the hands of whoever blew away modutils.
I worked around this properly, by fully demodularizing the kernel.
Anyway, thus far ppc64 comes up clean with no patches, ia64 comes up
clean with clameter's mmtimer patch. Other arches pending.
-- wli
On Wed, Jan 26, 2005 at 10:27:43PM +0300, Evgeniy Polyakov wrote:
>...
> I greatly appreciate your comments, and they were addressed.
> Part of exported symbols are unexported, patch is just waiting to be sent,
Ah, sorry. I only saw that the patch I sent two months ago still
applies completely (except for an unrelated context change).
> but I do not agree with dscore rename. I just do not understand it's advantage.
It is only a small cosmetic thing:
If there's only one object file in a module, a renaming in the Makefile
is superfluous - you can simply rename the source file
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, 2005-01-27 at 11:20 +0100, Adrian Bunk wrote:
> On Wed, Jan 26, 2005 at 10:27:43PM +0300, Evgeniy Polyakov wrote:
> >...
> > I greatly appreciate your comments, and they were addressed.
> > Part of exported symbols are unexported, patch is just waiting to be sent,
>
> Ah, sorry. I only saw that the patch I sent two months ago still
> applies completely (except for an unrelated context change).
Patch is alredy sent, but probably it will not apper in the nearest -mm
release.
> > but I do not agree with dscore rename. I just do not understand it's advantage.
>
> It is only a small cosmetic thing:
> If there's only one object file in a module, a renaming in the Makefile
> is superfluous - you can simply rename the source file
Most of it's exports are preparation for EEPROM driver, which will
require
some changes in w1 core(it needs to export additional callbacks).
I'm currently review DS device set to find any dependency upon ds2490
chip -
but it looks like there is no one, so it is alredy not core, but device
driver
itlself.
I'm not too religious about it's name...
> cu
> Adrian
>
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
Evgeniy Polyakov wrote:
> On Mon, 24 Jan 2005 18:54:49 +0100
> Adrian Bunk <[email protected]> wrote:
>
>
>>It seems noone who reviewed the SuperIO patches noticed that there are
>>now two modules "scx200" in the kernel...
>
>
> They are almost mutually exlusive(SuperIO contains more advanced),
> so I do not see any problem here.
> Only one of them can be loaded in a time.
>
> So what does exactly bother you?
>
That I don't know how to select loading between modules with the same
name. What's the trick?
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Sytse Wielinga wrote:
> Hi Andrew,
>
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>
>>fuse-transfer-readdir-data-through-device.patch
>> fuse: transfer readdir data through device
>
> It is great that this is fixed, don't remove it, but it does require the fuse
> libs to be updated at the same time, or opening dirs for listings will break
> like this:
>
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
> not implemented)
>
> As I personally like for my ls to keep on working, and I assume others will,
> too, I would appreciate it if you could add a warning to your announcements the
> following one or two weeks or so, so that people can remove this patch if they
> don't want to update their libs.
By any chance would this also break perl programs which readdir?
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Thu, Jan 27, 2005 at 10:45:09AM -0500, Bill Davidsen wrote:
> Sytse Wielinga wrote:
> >It is great that this is fixed, don't remove it, but it does require the fuse
> >libs to be updated at the same time, or opening dirs for listings will break
> >like this:
> >
> >open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
> >not implemented)
> >
> >As I personally like for my ls to keep on working, and I assume others will,
> >too, I would appreciate it if you could add a warning to your announcements the
> >following one or two weeks or so, so that people can remove this patch if they
> >don't want to update their libs.
>
> By any chance would this also break perl programs which readdir?
Of course; I haven't tested it, but the actual ioctls aren't working anymore,
so it's not even _possible_ to get them to work with this patch and an old
version of the fuse libs, even with perl bindings, which go through the fuse
libs anyway.
Sytse
On Thu, 27 Jan 2005 10:19:51 -0500
Bill Davidsen <[email protected]> wrote:
> Evgeniy Polyakov wrote:
> > On Mon, 24 Jan 2005 18:54:49 +0100
> > Adrian Bunk <[email protected]> wrote:
> >
> >
> >>It seems noone who reviewed the SuperIO patches noticed that there are
> >>now two modules "scx200" in the kernel...
> >
> >
> > They are almost mutually exlusive(SuperIO contains more advanced),
> > so I do not see any problem here.
> > Only one of them can be loaded in a time.
> >
> > So what does exactly bother you?
> >
> That I don't know how to select loading between modules with the same
> name. What's the trick?
Use full path.
Please see discussion in this thread related to module names.
> --
> -bill davidsen ([email protected])
> "The secret to procrastination is to put things off until the
> last possible moment - but no longer" -me
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
> > >As I personally like for my ls to keep on working, and I assume
> > >others will, too, I would appreciate it if you could add a
> > >warning to your announcements the following one or two weeks or
> > >so, so that people can remove this patch if they don't want to
> > >update their libs.
> >
> > By any chance would this also break perl programs which readdir?
>
> Of course; I haven't tested it, but the actual ioctls aren't working
> anymore, so it's not even _possible_ to get them to work with this
> patch and an old version of the fuse libs, even with perl bindings,
> which go through the fuse libs anyway.
First, a little clarification: FUSE doesn't use ioctl() for
communication between the kernel and userspace. It uses read() and
write().
That aside, you are right, that this change breaks any kind of FUSE
based filesystem. However the fix is trivial: install FUSE version
2.2-pre5 or later. The filesystems themselves don't need to be
rebuilt, since the fix in the shared library will automatically get
used.
Thanks,
Miklos
On Wed, 26 Jan 2005 15:22:52 -0500
Dmitry Torokhov <[email protected]> wrote:
> On Wed, 26 Jan 2005 23:07:12 +0300, Evgeniy Polyakov
> <[email protected]> wrote:
> >
> > Chip driver provides access methods to the attached logical devices.
> > It probes and activates them, if appropriate module is loaded.
> >
> > Your example again is not suitable for superio case.
> >
> > With superio you have several identical logical devices, access to which
> > is absolutely standard in second level(logic befind access),
> > but in first one(physicall access) it can differ.
> >
> > So here is the real example of superio usage:
> >
> > userspace
> > |
> > superio core
> > ......
> >
> > GPIO
> > |----| |--|
> > pc87366 sc1100
> > |----| |---|
> > WDT
> >
> > Logical device GPIO is accessed by read/write methods, which only have
> > pin number(it is not how this methods are exactly implemeted though)
> > as parameter.
> >
> > For example userspace accesses GPIO at sc1100 - it will be translated
> > into read methods called from appropriate superio chip with appropriate
> > parameters.
> >
> > When we have multiple GPIO logical devices(each in it's own superio chip)
> > it is more convenient to use just the same object.
>
> I take an exception to that. I think useroace is not concerned with
> topology and ownership of logical devices, the data is more important.
> I.e. you need to know that some pin respons to CPU temperature but you
> don't really care that it connected to it87 as opposed to some other
> chip. Therefore I think that ldev should translate to exactly the same
> underlying object. Consider the picture below:
>
> GPIO0 GPIO1 GPIO2 GPIO3
> | | | |
> pc87266 sc1100 blah123
> | |
> WDT0 WDT1
>
> This will allow:
> - map every hardware piece (not entire chip, separate functions) to a
> device file to userspace can use standard read/write/select/poll if
> choses so.
> - easily represent them in sysfs and also allow userspace access to
> individual bits through sysfs attributes.
> - will not give headaches with poer management when half of device is
> powered down and half is active.
> - provided that there are alternative interfaces outlined above
> superio can be decoupled from the connector.
With presented design we already have above links.
Each superio chip has a list of chain objects, each of which points to
the connected logical device.
Logical device usage must be done using provided logical device methods
(like read/write/control).
>From that point of view noone even knows, that above GPIO0 and GPIO1
(on the picture) are actually the same object(if they are not clones,
but if they are, then picture becomes 100% real).
> I wonder if it should be called "gpio" bus as opposed to superio
> because only chips are "super", the bus consists of very simple
> devices and drivers.
I can not agree that it is a bus.
Bus abstraction can be _only_ applied to hierarchy in the only one
superio chip.
> > I did not understand you from the beginning...
>
> We are getting there I believe ;)
>
> --
> Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
On Tue, Jan 25, 2005 at 01:03:39AM +0100, Sytse Wielinga wrote:
> Hi Andrew,
>
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > fuse-transfer-readdir-data-through-device.patch
> > fuse: transfer readdir data through device
> It is great that this is fixed, don't remove it, but it does require the fuse
> libs to be updated at the same time, or opening dirs for listings will break
> like this:
fuse is a new feature, so we'll sort out all issues before it goes to mainline.
I'm sure once it's under review there will be a few more changes in the
kernel <-> userland interface.
On Thu, 27 Jan 2005, Evgeniy Polyakov wrote:
> On Thu, 27 Jan 2005 10:19:51 -0500
> Bill Davidsen <[email protected]> wrote:
>
> > Evgeniy Polyakov wrote:
> > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > Adrian Bunk <[email protected]> wrote:
> > >
> > >
> > >>It seems noone who reviewed the SuperIO patches noticed that there are
> > >>now two modules "scx200" in the kernel...
> > >
> > >
> > > They are almost mutually exlusive(SuperIO contains more advanced),
> > > so I do not see any problem here.
> > > Only one of them can be loaded in a time.
> > >
> > > So what does exactly bother you?
> > >
> > That I don't know how to select loading between modules with the same
> > name. What's the trick?
>
> Use full path.
> Please see discussion in this thread related to module names.
Ah-ha! I looked at the man page instead of the code. It's not obvious the
"modulename" can be a full path, but the (possibly old) man page I have
for modprobe.conf could be out of date. I'll go look at the code.
Thanks.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, 2005-01-24 at 12:17 +0000, Christoph Hellwig wrote:
> Haven't had time to look at the current implementation, but the in-kernel
> interface is still horrible as it duplicates the dnotify calls all over the
> place, using IN_FOO instead of DN_FOO. Please add a layer of notify_foo
> wrappers that calls into both.
Hi, Christoph!
I went ahead and wrote a generic notification layer, wrapping inotify,
dnotify, and some related work behind nice, clean interfaces such as
"fsnotify_move()".
The patch is a net gain of -125 lines ignoring the new
<linux/fsnotify.h>, so it does remove a bit of code from fs/, which is
nice.
Compile tested, but not yet booted. Find an interdiff below, so you can
get an idea of the interfaces, at least.
If this is really an issue for you, I think that this should be a step
in the right direction.
Best,
Robert Love
Signed-off-by: Robert Love <[email protected]>
diff -u linux/fs/attr.c linux/fs/attr.c
--- linux/fs/attr.c 2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/attr.c 2005-01-31 15:52:37.756482208 -0500
@@ -10,8 +10,7 @@
#include <linux/mm.h>
#include <linux/string.h>
#include <linux/smp_lock.h>
-#include <linux/dnotify.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
#include <linux/fcntl.h>
#include <linux/quotaops.h>
#include <linux/security.h>
@@ -106,51 +105,6 @@
}
EXPORT_SYMBOL(inode_setattr);
-void setattr_mask (unsigned int ia_valid, int *dn_mask, u32 *in_mask)
-{
- int dnmask;
- u32 inmask;
-
- inmask = 0;
- dnmask = 0;
-
- if (!dn_mask || !in_mask) {
- return;
- }
- if (ia_valid & ATTR_UID) {
- inmask |= IN_ATTRIB;
- dnmask |= DN_ATTRIB;
- }
- if (ia_valid & ATTR_GID) {
- inmask |= IN_ATTRIB;
- dnmask |= DN_ATTRIB;
- }
- if (ia_valid & ATTR_SIZE) {
- inmask |= IN_MODIFY;
- dnmask |= DN_MODIFY;
- }
- /* both times implies a utime(s) call */
- if ((ia_valid & (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME)) {
- inmask |= IN_ATTRIB;
- dnmask |= DN_ATTRIB;
- }
- else if (ia_valid & ATTR_ATIME) {
- inmask |= IN_ACCESS;
- dnmask |= DN_ACCESS;
- }
- else if (ia_valid & ATTR_MTIME) {
- inmask |= IN_MODIFY;
- dnmask |= DN_MODIFY;
- }
- if (ia_valid & ATTR_MODE) {
- inmask |= IN_ATTRIB;
- dnmask |= DN_ATTRIB;
- }
-
- *in_mask = inmask;
- *dn_mask = dnmask;
-}
-
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry->d_inode;
@@ -206,21 +160,10 @@
error = inode_setattr(inode, attr);
}
}
- if (!error) {
- int dn_mask;
- u32 in_mask;
- setattr_mask (ia_valid, &dn_mask, &in_mask);
+ if (!error)
+ fsnotify_change(dentry, ia_valid);
- if (dn_mask)
- dnotify_parent(dentry, dn_mask);
- if (in_mask) {
- inotify_inode_queue_event(dentry->d_inode, in_mask, 0,
- NULL);
- inotify_dentry_parent_queue_event(dentry, in_mask, 0,
- dentry->d_name.name);
- }
- }
return error;
}
diff -u linux/fs/file_table.c linux/fs/file_table.c
--- linux/fs/file_table.c 2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/file_table.c 2005-01-31 15:46:49.248463480 -0500
@@ -16,7 +16,7 @@
#include <linux/eventpoll.h>
#include <linux/mount.h>
#include <linux/cdev.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
/* sysctl tunables... */
struct files_stat_struct files_stat = {
@@ -121,12 +121,9 @@
struct dentry *dentry = file->f_dentry;
struct vfsmount *mnt = file->f_vfsmnt;
struct inode *inode = dentry->d_inode;
- u32 mask;
- mask = (file->f_mode & FMODE_WRITE) ? IN_CLOSE_WRITE : IN_CLOSE_NOWRITE;
- inotify_dentry_parent_queue_event(dentry, mask, 0, dentry->d_name.name);
- inotify_inode_queue_event(inode, mask, 0, NULL);
+ fsnotify_close(dentry, inode, file->f_mode, dentry->d_name.name);
might_sleep();
/*
diff -u linux/fs/namei.c linux/fs/namei.c
--- linux/fs/namei.c 2005-01-20 15:32:24.000000000 -0500
+++ linux/fs/namei.c 2005-01-31 17:24:21.870729656 -0500
@@ -21,8 +21,7 @@
#include <linux/namei.h>
#include <linux/quotaops.h>
#include <linux/pagemap.h>
-#include <linux/dnotify.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
#include <linux/smp_lock.h>
#include <linux/personality.h>
#include <linux/security.h>
@@ -1242,9 +1241,7 @@
DQUOT_INIT(dir);
error = dir->i_op->create(dir, dentry, mode, nd);
if (!error) {
- inode_dir_notify(dir, DN_CREATE);
- inotify_inode_queue_event(dir, IN_CREATE_FILE,
- 0, dentry->d_name.name);
+ fsnotify_create(dir, dentry->d_name.name);
security_inode_post_create(dir, dentry, mode);
}
return error;
@@ -1558,9 +1555,7 @@
DQUOT_INIT(dir);
error = dir->i_op->mknod(dir, dentry, mode, dev);
if (!error) {
- inode_dir_notify(dir, DN_CREATE);
- inotify_inode_queue_event(dir, IN_CREATE_FILE, 0,
- dentry->d_name.name);
+ fsnotify_create(dir, dentry->d_name.name);
security_inode_post_mknod(dir, dentry, mode, dev);
}
return error;
@@ -1633,9 +1628,7 @@
DQUOT_INIT(dir);
error = dir->i_op->mkdir(dir, dentry, mode);
if (!error) {
- inode_dir_notify(dir, DN_CREATE);
- inotify_inode_queue_event(dir, IN_CREATE_SUBDIR, 0,
- dentry->d_name.name);
+ fsnotify_mkdir(dir, dentry->d_name.name);
security_inode_post_mkdir(dir,dentry, mode);
}
return error;
@@ -1729,15 +1722,8 @@
}
}
up(&dentry->d_inode->i_sem);
- if (!error) {
- inode_dir_notify(dir, DN_DELETE);
- inotify_inode_queue_event(dir, IN_DELETE_SUBDIR, 0,
- dentry->d_name.name);
- inotify_inode_queue_event(dentry->d_inode, IN_DELETE_SELF, 0,
- NULL);
- inotify_inode_is_dead (dentry->d_inode);
- d_delete(dentry);
- }
+ if (!error)
+ fsnotify_rmdir(dentry, dentry->d_inode, dir);
dput(dentry);
return error;
@@ -1807,15 +1793,9 @@
up(&dentry->d_inode->i_sem);
/* We don't d_delete() NFS sillyrenamed files--they still exist. */
- if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
- inode_dir_notify(dir, DN_DELETE);
- inotify_inode_queue_event(dir, IN_DELETE_FILE, 0,
- dentry->d_name.name);
- inotify_inode_queue_event(dentry->d_inode, IN_DELETE_SELF, 0,
- NULL);
- inotify_inode_is_dead (dentry->d_inode);
- d_delete(dentry);
- }
+ if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED))
+ fsnotify_unlink(dentry->d_inode, dir, dentry);
+
return error;
}
@@ -1889,9 +1869,7 @@
DQUOT_INIT(dir);
error = dir->i_op->symlink(dir, dentry, oldname);
if (!error) {
- inode_dir_notify(dir, DN_CREATE);
- inotify_inode_queue_event(dir, IN_CREATE_FILE, 0,
- dentry->d_name.name);
+ fsnotify_create(dir, dentry->d_name.name);
security_inode_post_symlink(dir, dentry, oldname);
}
return error;
@@ -1964,9 +1942,7 @@
error = dir->i_op->link(old_dentry, dir, new_dentry);
up(&old_dentry->d_inode->i_sem);
if (!error) {
- inode_dir_notify(dir, DN_CREATE);
- inotify_inode_queue_event(dir, IN_CREATE_FILE, 0,
- new_dentry->d_name.name);
+ fsnotify_create(dir, new_dentry->d_name.name);
security_inode_post_link(old_dentry, dir, new_dentry);
}
return error;
@@ -2131,7 +2107,6 @@
int error;
int is_dir = S_ISDIR(old_dentry->d_inode->i_mode);
char *old_name;
- u32 cookie;
if (old_dentry->d_inode == new_dentry->d_inode)
return 0;
@@ -2153,28 +2128,17 @@
DQUOT_INIT(old_dir);
DQUOT_INIT(new_dir);
- old_name = inotify_oldname_init(old_dentry);
+ old_name = fsnotify_oldname_init(old_dentry);
if (is_dir)
error = vfs_rename_dir(old_dir,old_dentry,new_dir,new_dentry);
else
error = vfs_rename_other(old_dir,old_dentry,new_dir,new_dentry);
if (!error) {
- if (old_dir == new_dir)
- inode_dir_notify(old_dir, DN_RENAME);
- else {
- inode_dir_notify(old_dir, DN_DELETE);
- inode_dir_notify(new_dir, DN_CREATE);
- }
-
- cookie = inotify_get_cookie();
-
- inotify_inode_queue_event(old_dir, IN_MOVED_FROM, cookie,
- old_name);
- inotify_inode_queue_event(new_dir, IN_MOVED_TO, cookie,
- old_dentry->d_name.name);
+ const char *new_name = old_dentry->d_name.name;
+ fsnotify_move(old_dir, new_dir, old_name, new_name);
}
- inotify_oldname_free(old_name);
+ fsnotify_oldname_free(old_name);
return error;
}
diff -u linux/fs/open.c linux/fs/open.c
--- linux/fs/open.c 2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/open.c 2005-01-31 16:28:33.478762608 -0500
@@ -10,8 +10,7 @@
#include <linux/file.h>
#include <linux/smp_lock.h>
#include <linux/quotaops.h>
-#include <linux/dnotify.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/tty.h>
@@ -954,13 +953,13 @@
fd = get_unused_fd();
if (fd >= 0) {
struct file *f = filp_open(tmp, flags, mode);
+ struct dentry *dentry = f->f_dentry;
+
error = PTR_ERR(f);
if (IS_ERR(f))
goto out_error;
- inotify_inode_queue_event(f->f_dentry->d_inode,
- IN_OPEN, 0, NULL);
- inotify_dentry_parent_queue_event(f->f_dentry, IN_OPEN,
- 0, f->f_dentry->d_name.name);
+ fsnotify_open(dentry, dentry->d_inode,
+ dentry->d_name.name);
fd_install(fd, f);
}
out:
@@ -1012,7 +1011,7 @@
retval = err;
}
- dnotify_flush(filp, id);
+ fsnotify_flush(filp, id);
locks_remove_posix(filp, id);
fput(filp);
return retval;
diff -u linux/fs/read_write.c linux/fs/read_write.c
--- linux/fs/read_write.c 2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/read_write.c 2005-01-31 16:35:05.270201256 -0500
@@ -10,8 +10,7 @@
#include <linux/file.h>
#include <linux/uio.h>
#include <linux/smp_lock.h>
-#include <linux/dnotify.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
#include <linux/security.h>
#include <linux/module.h>
#include <linux/syscalls.h>
@@ -219,11 +218,8 @@
ret = do_sync_read(file, buf, count, pos);
if (ret > 0) {
struct dentry *dentry = file->f_dentry;
- dnotify_parent(dentry, DN_ACCESS);
- inotify_dentry_parent_queue_event(dentry,
- IN_ACCESS, 0, dentry->d_name.name);
- inotify_inode_queue_event(inode, IN_ACCESS, 0,
- NULL);
+ fsnotify_access(dentry, inode,
+ dentry->d_name.name);
}
}
}
@@ -269,11 +265,8 @@
ret = do_sync_write(file, buf, count, pos);
if (ret > 0) {
struct dentry *dentry = file->f_dentry;
- dnotify_parent(dentry, DN_MODIFY);
- inotify_dentry_parent_queue_event(dentry,
- IN_MODIFY, 0, dentry->d_name.name);
- inotify_inode_queue_event(inode, IN_MODIFY, 0,
- NULL);
+ fsnotify_modify(dentry, inode,
+ dentry->d_name.name);
}
}
}
@@ -508,12 +501,12 @@
kfree(iov);
if ((ret + (type == READ)) > 0) {
struct dentry *dentry = file->f_dentry;
- dnotify_parent(dentry, (type == READ) ? DN_ACCESS : DN_MODIFY);
- inotify_dentry_parent_queue_event(dentry,
- (type == READ) ? IN_ACCESS : IN_MODIFY, 0,
- dentry->d_name.name);
- inotify_inode_queue_event (dentry->d_inode,
- (type == READ) ? IN_ACCESS : IN_MODIFY, 0, NULL);
+ struct inode *inode = dentry->d_inode;
+
+ if (type == READ)
+ fsnotify_access(dentry, inode, dentry->d_name.name);
+ else
+ fsnotify_modify(dentry, inode, dentry->d_name.name);
}
return ret;
}
diff -u linux/fs/super.c linux/fs/super.c
--- linux/fs/super.c 2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/super.c 2005-01-31 14:53:38.828481040 -0500
@@ -37,9 +37,8 @@
#include <linux/writeback.h> /* for the emergency remount stuff */
#include <linux/idr.h>
#include <linux/kobject.h>
+#include <linux/fsnotify.h>
#include <asm/uaccess.h>
-#include <linux/inotify.h>
-
void get_filesystem(struct file_system_type *fs);
void put_filesystem(struct file_system_type *fs);
@@ -228,7 +227,7 @@
if (root) {
sb->s_root = NULL;
- inotify_super_block_umount(sb);
+ fsnotify_sb_umount(sb);
shrink_dcache_parent(root);
shrink_dcache_anon(&sb->s_anon);
dput(root);
diff -u linux/include/linux/inotify.h linux/include/linux/inotify.h
--- linux/include/linux/inotify.h 2005-01-18 16:11:12.000000000 -0500
+++ linux/include/linux/inotify.h 2005-01-31 17:22:43.129740568 -0500
@@ -84,23 +84,6 @@
extern void inotify_super_block_umount(struct super_block *);
extern void inotify_inode_is_dead(struct inode *);
extern __u32 inotify_get_cookie(void);
-extern __u32 setattr_mask_inotify(unsigned int);
-
-/* this could be kstrdup if only we could add that to lib/string.c */
-static inline char * inotify_oldname_init(struct dentry *old_dentry)
-{
- char *old_name;
-
- old_name = kmalloc(strlen(old_dentry->d_name.name) + 1, GFP_KERNEL);
- if (old_name)
- strcpy(old_name, old_dentry->d_name.name);
- return old_name;
-}
-
-static inline void inotify_oldname_free(const char *old_name)
-{
- kfree(old_name);
-}
#else
@@ -124,25 +107,11 @@
{
}
-static inline char * inotify_oldname_init(struct dentry *old_dentry)
-{
- return NULL;
-}
-
static inline __u32 inotify_get_cookie(void)
{
return 0;
}
-static inline void inotify_oldname_free(const char *old_name)
-{
-}
-
-static inline int setattr_mask_inotify(unsigned int ia_mask)
-{
- return 0;
-}
-
#endif /* CONFIG_INOTIFY */
#endif /* __KERNEL __ */
only in patch2:
unchanged:
--- linux-2.6.10/fs/compat.c 2004-12-24 16:34:44.000000000 -0500
+++ linux/fs/compat.c 2005-01-31 17:08:03.561455272 -0500
@@ -1192,9 +1192,15 @@
out:
if (iov != iovstack)
kfree(iov);
- if ((ret + (type == READ)) > 0)
- dnotify_parent(file->f_dentry,
- (type == READ) ? DN_ACCESS : DN_MODIFY);
+ if ((ret + (type == READ)) > 0) {
+ struct dentry *dentry = file->f_dentry;
+ if (type == READ)
+ fsnotify_access(dentry, dentry->d_inode,
+ dentry->d_name.name);
+ else
+ fsnotify_modify(dentry, dentry->d_inode,
+ dentry->d_name.name);
+ }
return ret;
}
only in patch2:
unchanged:
--- linux-2.6.10/include/linux/fsnotify.h 1969-12-31 19:00:00.000000000 -0500
+++ linux/include/linux/fsnotify.h 2005-01-31 17:24:54.486771264 -0500
@@ -0,0 +1,225 @@
+#ifndef _LINUX_FS_NOTIFY_H
+#define _LINUX_FS_NOTIFY_H
+
+/*
+ * include/linux/fs_notify.h - generic hooks for filesystem notification, to
+ * reduce in-source duplication from both dnotify and inotify.
+ *
+ * We don't compile any of this away in some complicated menagerie of ifdefs.
+ * Instead, we rely on the code inside to optimize away as needed.
+ *
+ * (C) Copyright 2005 Robert Love
+ */
+
+#ifdef __KERNEL__
+
+#include <linux/dnotify.h>
+#include <linux/inotify.h>
+
+/*
+ * fsnotify_move - file old_name at old_dir was moved to new_name at new_dir
+ */
+static inline void fsnotify_move(struct inode *old_dir, struct inode *new_dir,
+ const char *old_name, const char *new_name)
+{
+ u32 cookie;
+
+ if (old_dir == new_dir)
+ inode_dir_notify(old_dir, DN_RENAME);
+ else {
+ inode_dir_notify(old_dir, DN_DELETE);
+ inode_dir_notify(new_dir, DN_CREATE);
+ }
+
+ cookie = inotify_get_cookie();
+
+ inotify_inode_queue_event(old_dir, IN_MOVED_FROM, cookie, old_name);
+ inotify_inode_queue_event(new_dir, IN_MOVED_TO, cookie, new_name);
+}
+
+/*
+ * fsnotify_unlink - file was unlinked
+ */
+static inline void fsnotify_unlink(struct inode *inode, struct inode *dir,
+ struct dentry *dentry)
+{
+ inode_dir_notify(dir, DN_DELETE);
+ inotify_inode_queue_event(dir, IN_DELETE_FILE, 0, dentry->d_name.name);
+ inotify_inode_queue_event(inode, IN_DELETE_SELF, 0, NULL);
+
+ inotify_inode_is_dead(inode);
+ d_delete(dentry);
+}
+
+/*
+ * fsnotify_rmdir - directory was removed
+ */
+static inline void fsnotify_rmdir(struct dentry *dentry, struct inode *inode,
+ struct inode *dir)
+{
+ inode_dir_notify(dir, DN_DELETE);
+ inotify_inode_queue_event(dir, IN_DELETE_SUBDIR,0,dentry->d_name.name);
+ inotify_inode_queue_event(inode, IN_DELETE_SELF, 0, NULL);
+
+ inotify_inode_is_dead(inode);
+ d_delete(dentry);
+}
+
+/*
+ * fsnotify_create - filename was linked in
+ */
+static inline void fsnotify_create(struct inode *inode, const char *filename)
+{
+ inode_dir_notify(inode, DN_CREATE);
+ inotify_inode_queue_event(inode, IN_CREATE_FILE, 0, filename);
+}
+
+/*
+ * fsnotify_mkdir - directory 'name' was created
+ */
+static inline void fsnotify_mkdir(struct inode *inode, const char *name)
+{
+ inode_dir_notify(inode, DN_CREATE);
+ inotify_inode_queue_event(inode, IN_CREATE_SUBDIR, 0, name);
+}
+
+/*
+ * fsnotify_access - file was read
+ */
+static inline void fsnotify_access(struct dentry *dentry, struct inode *inode,
+ const char *filename)
+{
+ dnotify_parent(dentry, DN_ACCESS);
+ inotify_dentry_parent_queue_event(dentry, IN_ACCESS, 0,
+ dentry->d_name.name);
+ inotify_inode_queue_event(inode, IN_ACCESS, 0, NULL);
+}
+
+/*
+ * fsnotify_modify - file was modified
+ */
+static inline void fsnotify_modify(struct dentry *dentry, struct inode *inode,
+ const char *filename)
+{
+ dnotify_parent(dentry, DN_MODIFY);
+ inotify_dentry_parent_queue_event(dentry, IN_MODIFY, 0, filename);
+ inotify_inode_queue_event(inode, IN_MODIFY, 0, NULL);
+}
+
+/*
+ * fsnotify_open - file was opened
+ */
+static inline void fsnotify_open(struct dentry *dentry, struct inode *inode,
+ const char *filename)
+{
+ inotify_inode_queue_event(inode, IN_OPEN, 0, NULL);
+ inotify_dentry_parent_queue_event(dentry, IN_OPEN, 0, filename);
+}
+
+/*
+ * fsnotify_close - file was closed
+ */
+static inline void fsnotify_close(struct dentry *dentry, struct inode *inode,
+ mode_t mode, const char *filename)
+{
+ u32 mask;
+
+ mask = (mode & FMODE_WRITE) ? IN_CLOSE_WRITE : IN_CLOSE_NOWRITE;
+ inotify_dentry_parent_queue_event(dentry, mask, 0, filename);
+ inotify_inode_queue_event(inode, mask, 0, NULL);
+}
+
+/*
+ * fsnotify_change - notify_change event. file was modified and/or metadata
+ * was changed.
+ */
+static inline void fsnotify_change(struct dentry *dentry, unsigned int ia_valid)
+{
+ int dn_mask = 0;
+ u32 in_mask = 0;
+
+ if (ia_valid & ATTR_UID) {
+ in_mask |= IN_ATTRIB;
+ dn_mask |= DN_ATTRIB;
+ }
+ if (ia_valid & ATTR_GID) {
+ in_mask |= IN_ATTRIB;
+ dn_mask |= DN_ATTRIB;
+ }
+ if (ia_valid & ATTR_SIZE) {
+ in_mask |= IN_MODIFY;
+ dn_mask |= DN_MODIFY;
+ }
+ /* both times implies a utime(s) call */
+ if ((ia_valid & (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME)) {
+ in_mask |= IN_ATTRIB;
+ dn_mask |= DN_ATTRIB;
+ }
+ else if (ia_valid & ATTR_ATIME) {
+ in_mask |= IN_ACCESS;
+ dn_mask |= DN_ACCESS;
+ }
+ else if (ia_valid & ATTR_MTIME) {
+ in_mask |= IN_MODIFY;
+ dn_mask |= DN_MODIFY;
+ }
+ if (ia_valid & ATTR_MODE) {
+ in_mask |= IN_ATTRIB;
+ dn_mask |= DN_ATTRIB;
+ }
+
+ if (dn_mask)
+ dnotify_parent(dentry, dn_mask);
+ if (in_mask) {
+ inotify_inode_queue_event(dentry->d_inode, in_mask, 0, NULL);
+ inotify_dentry_parent_queue_event(dentry, in_mask, 0,
+ dentry->d_name.name);
+ }
+}
+
+/*
+ * fsnotify_sb_umount - filesystem unmount
+ */
+static inline void fsnotify_sb_umount(struct super_block *sb)
+{
+ inotify_super_block_umount(sb);
+}
+
+/*
+ * fsnotify_flush - flush time!
+ */
+static inline void fsnotify_flush(struct file *filp, fl_owner_t id)
+{
+ dnotify_flush(filp, id);
+}
+
+#ifdef CONFIG_INOTIFY /* inotify helpers */
+
+/*
+ * fsnotify_oldname_init - save off the old filename before we change it
+ *
+ * this could be kstrdup if only we could add that to lib/string.c
+ */
+static inline char * fsnotify_oldname_init(struct dentry *old_dentry)
+{
+ char *old_name;
+
+ old_name = kmalloc(strlen(old_dentry->d_name.name) + 1, GFP_KERNEL);
+ if (old_name)
+ strcpy(old_name, old_dentry->d_name.name);
+ return old_name;
+}
+
+/*
+ * fsnotify_oldname_free - free the name we got from fsnotify_oldname_init
+ */
+static inline void fsnotify_oldname_free(const char *old_name)
+{
+ kfree(old_name);
+}
+
+#endif /* CONFIG_INOTIFY */
+
+#endif /* __KERNEL__ */
+
+#endif /* _LINUX_FS_NOTIFY_H */
* Christoph Hellwig <[email protected]> wrote:
> > inotify.patch
> > inotify
> Also ioctl is not an acceptable interface for adding new core
> functionality.
seconded. Robert?
Ingo
On Mon, 2005-02-07 at 12:57 +0100, Ingo Molnar wrote:
Hello, Ingo.
> > Also ioctl is not an acceptable interface for adding new core
> > functionality.
>
> seconded. Robert?
Well, I don't share the hatred for ioctl, at least compared to another
type unsafe interface like write().
But John and I are open to doing whatever is the consensus. If there is
an agreed alternative, and that is the requirement for merging, I'll do
it.
I'd like to keep the user-space interface and simple, and absolutely
want to keep the single file descriptor approach. How the fd is
obtained is up for discussion.
Ingo, what do you prefer?
Best,
Robert Love
On Mon, 2005-02-07 at 12:30 -0500, Robert Love wrote:
> Well, I don't share the hatred for ioctl, at least compared to another
> type unsafe interface like write().
>
> But John and I are open to doing whatever is the consensus. If there is
> an agreed alternative, and that is the requirement for merging, I'll do
> it.
Yes, if ioctl is unacceptable, then providing a write() interface is
what we will do.
>
> I'd like to keep the user-space interface and simple, and absolutely
> want to keep the single file descriptor approach. How the fd is
> obtained is up for discussion.
I would still like to keep the character device as the interface for
getting the fd. I don't see what benefit could be gained by converting
to a syscall based interface for getting the fd.
--
John McCutchan <[email protected]>