From owner-devfs@oss.sgi.com Thu Jul 5 13:23:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f65KNo230038 for devfs-outgoing; Thu, 5 Jul 2001 13:23:50 -0700 Received: from odin.oce.srci.oce.int ([208.187.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f65KNdV30019 for ; Thu, 5 Jul 2001 13:23:39 -0700 Received: from mindless.com (widmers.oce.srci.oce.int [10.2.1.34]) by odin.oce.srci.oce.int; Thu, 05 Jul 2001 14:23:24 -0600 Message-ID: <3B44CC4B.7010300@mindless.com> Date: Thu, 05 Jul 2001 14:21:31 -0600 From: "Joshua M. Schmidlkofer" Reply-To: menion@fmtc.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010704 X-Accept-Language: en-us MIME-Version: 1.0 To: devfs Subject: PTS/? with incorrect ownership. Content-Type: multipart/mixed; boundary="------------040403070400000606040506" Sender: owner-devfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------040403070400000606040506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Howdy, I am using UNIX98 PTY's, and using strictly devfs to manage the 'devpts'. [a.k.a. no devpts fs support in my kernel]. For some reason, under X I am experiencing a semi-random but frequent inability to start terms of any kind. I have been trying to narrow the problem down, however, I am not having good success. I added an event to devfsd that executed a script....: 'REGISTER pts/.* EXECUTE /bin/logperms.sh' 'UNREGISTER pts/.* EXECUTE /bin/logperms.sh' And I found that the files are being created w/incorrect ownership. I started parsing through kernel code, examining char/pty.c, char/tty_io.c, and devfs/base.c. I can follow the path of execution, but I fail to see where the ownership could be mistaken. As I started to try and read it, it came upon me that I was going to have to learn about process management in the kernel. This seems a bit of a steep climb from the hole that I am in. [esp. when I can't open any new terminal. *laugh*]. Here are the symptoms: _SOMETIMES_ terminals will start properly, and when they do, I will be able to open 5 or 6 or maybe even 10, but eventually the system will halt opening new terminals. If I try to open a new one, then it immediatly dies. If I start it from within an open one [i.e. rxvt&] I get a message: 'unable to open slave pty'. I read through rxvt to that point, and the code indicates that an open of /dev/pts/[??] failed. Using the REGISTER event, I was able to see that the device had an improper ownership. Further examination of the code SEEMED to indicate that devfs _should_ have the device properly set before notifying devfsd.... To further obscure the problem, I am using KDE, and if I modify the link which starts the term, and add check 'run in terminal', then _usually_ the system returns to opening terminal normally. Occasionally that does not work, so I have tried going into /dev/pts, and creating [mknod'ing] the next device in line, and explicitly setting ownership. Then, usually, the next terminal I open as the user will use THAT node, and work fine. However, after that, with no discernable pattern, things stop working. I am stumped, and I am including my config, thus you can determine things like: 'Yes, he had plenty of UNIX98 Pty's configured.' thanks, Joshua Schmidlkofer Configuration info: Redhat 7.1, with the latest patches availible, as of 2001-07-03 KDE 2.1.1 - Stock with the distro Kernels: I have had this under 2.4.4 [a little], 2.4.5 [worse], 2.4.6 [just as bad a .5] Systems: 1: System, is a K6-2, with 219+meg, and an NVidia GeForce2MX, ALI Chipset MB, DEC21041 [Tulip] - Nvidia Drivers, no apgart, no dri. 2: HP Vectra, P-III [500], 192Meg, Intel 440BX/ZXmb, Embedded Matrox G200AGP, argart, dri, 3c905 Both systems are IDE, and both have been installed in the last 2 -3 months. [Obviously]. I have not gone back to 2.4.4, because I use Reiserfs, and I am a little leary of some bug in 2.4.4.... --------------040403070400000606040506 Content-Type: text/plain; name=".config" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=".config" # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=y # CONFIG_X86_MSR is not set CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y # CONFIG_RTNETLINK is not set # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD7409 is not set # CONFIG_AMD7409_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_OSB4 is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # # SCSI support # # CONFIG_SCSI is not set # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=y # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set # CONFIG_EL3 is not set # CONFIG_3C515 is not set # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=y # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set # CONFIG_NET_PCI is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # # CONFIG_INPUT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # CONFIG_PRINTER is not set # CONFIG_PPDEV is not set # # I2C support # CONFIG_I2C=y CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_PHILIPSPAR is not set # CONFIG_I2C_ELV is not set # CONFIG_I2C_VELLEMAN is not set CONFIG_I2C_ALGOPCF=y # CONFIG_I2C_ELEKTOR is not set CONFIG_I2C_CHARDEV=y # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=y CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # # Joysticks # # CONFIG_JOYSTICK is not set # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # CONFIG_SOFT_WATCHDOG is not set # CONFIG_WDT is not set # CONFIG_WDTPCI is not set # CONFIG_PCWATCHDOG is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_MIXCOMWD is not set # CONFIG_I810_TCO is not set # CONFIG_MACHZ_WDT is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y CONFIG_AGP_INTEL=y # CONFIG_AGP_I810 is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_ALI is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set CONFIG_DRM_MGA=y # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # CONFIG_QUOTA=y # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_FAT_FS=y # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=y # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y # CONFIG_DEVFS_DEBUG is not set # CONFIG_DEVPTS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # CONFIG_CODA_FS=m CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_SMB_FS=y CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp437" CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y # CONFIG_NCPFS_STRONG is not set CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y # CONFIG_FB_RIVA is not set # CONFIG_FB_CLGEN is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_VESA is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_HGA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_E1355 is not set CONFIG_FB_MATROX=m # CONFIG_FB_MATROX_MILLENIUM is not set # CONFIG_FB_MATROX_MYSTIQUE is not set CONFIG_FB_MATROX_G100=y CONFIG_FB_MATROX_I2C=m # CONFIG_FB_MATROX_MAVEN is not set # CONFIG_FB_MATROX_G450 is not set # CONFIG_FB_MATROX_MULTIHEAD is not set # CONFIG_FB_ATY is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_SIS is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FBCON_ADVANCED is not set CONFIG_FBCON_CFB8=m CONFIG_FBCON_CFB16=m CONFIG_FBCON_CFB24=m CONFIG_FBCON_CFB32=m # CONFIG_FBCON_FONTWIDTH8_ONLY is not set # CONFIG_FBCON_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Sound # CONFIG_SOUND=y # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set CONFIG_SOUND_FUSION=m CONFIG_SOUND_CS4281=m # CONFIG_SOUND_ES1370 is not set CONFIG_SOUND_ES1371=m # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set CONFIG_SOUND_OSS=m # CONFIG_SOUND_TRACEINIT is not set # CONFIG_SOUND_DMAP is not set # CONFIG_SOUND_AD1816 is not set # CONFIG_SOUND_SGALAXY is not set # CONFIG_SOUND_ADLIB is not set # CONFIG_SOUND_ACI_MIXER is not set # CONFIG_SOUND_CS4232 is not set # CONFIG_SOUND_SSCAPE is not set # CONFIG_SOUND_GUS is not set # CONFIG_SOUND_VMIDI is not set # CONFIG_SOUND_TRIX is not set # CONFIG_SOUND_MSS is not set # CONFIG_SOUND_MPU401 is not set # CONFIG_SOUND_NM256 is not set # CONFIG_SOUND_MAD16 is not set # CONFIG_SOUND_PAS is not set # CONFIG_PAS_JOYSTICK is not set # CONFIG_SOUND_PSS is not set # CONFIG_SOUND_SB is not set # CONFIG_SOUND_AWE32_SYNTH is not set # CONFIG_SOUND_WAVEFRONT is not set # CONFIG_SOUND_MAUI is not set # CONFIG_SOUND_YM3812 is not set # CONFIG_SOUND_OPL3SA1 is not set # CONFIG_SOUND_OPL3SA2 is not set # CONFIG_SOUND_YMFPCI is not set # CONFIG_SOUND_YMFPCI_LEGACY is not set # CONFIG_SOUND_UART6850 is not set # CONFIG_SOUND_AEDSP16 is not set # CONFIG_SOUND_TVMIXER is not set # # USB support # # CONFIG_USB is not set # # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set --------------040403070400000606040506-- From owner-devfs@oss.sgi.com Sat Jul 7 14:31:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f67LVlA23048 for devfs-outgoing; Sat, 7 Jul 2001 14:31:47 -0700 Received: from relay.ioffe.rssi.ru (root@relay.ioffe.rssi.ru [194.85.224.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f67LViV23044 for ; Sat, 7 Jul 2001 14:31:44 -0700 Received: from hilbert.pdmi.ras.ru (hilbert.pdmi.ras.ru [195.208.36.7]) by relay.ioffe.rssi.ru (8.9.1/8.9.1) with ESMTP id BAA29169 for ; Sun, 8 Jul 2001 01:31:38 +0400 (MSD) Received: from gauss.pdmi.ras.ru (gauss.pdmi.ras.ru [195.208.36.3]) by hilbert.pdmi.ras.ru (8.9.3/8.9.3/Debian/GNU) with ESMTP id BAA22675 for ; Sun, 8 Jul 2001 01:07:42 +0400 Received: from svivano.pdmi.ras.ru (uucp@localhost) by gauss.pdmi.ras.ru (8.8.8/8.8.8/Debian/GNU) with UUCP id BAA10659 for oss.sgi.com!devfs; Sun, 8 Jul 2001 01:31:04 +0400 Received: from localhost by svivano.pdmi.ras.ru with esmtp (Smail-3.2 1996-Jul-4 #1) id m15Izm4-000LnwC for ; Sun, 8 Jul 2001 01:38:00 +0400 (MSD) Date: Sun, 8 Jul 2001 01:38:00 +0400 (MSD) From: Sergei Ivanov X-X-Sender: To: Subject: autoloading modules Message-ID: Organization: Steklov Institute of Mathematics at St.Petersburg MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello I just tried devfs for the first time. After fixing a number of configuration issues, I found one that looks like a design problem in devfs (of course, given my poor knowledge of it). I am using kernel 2.4.6, glibc-2.2.3 and devfsd-1.3.11. The machine has a disc and a CD-ROM, used to be /dev/hda and /dev/hdb. The disc driver is in the kernel, and CD-ROM support is in modules. Without devfs, I have /dev/hda and /dev/hdb. When /dev/hdb is accessed, ide-cd module gets loaded. I don't know how this happens, probably the kernel uses the results of IDE probe to find out which module to load. With devfs, there is no /dev/hdb. This is ok, devfsd is supposed to manage it. (And it does so with some other devices - e.g. /dev/ttyS1 works though the serial driver is modular.) But not so with ide-cd. It is not autoloaded when /dev/hdb is referenced. Well, /dev/hdb is an old name, maybe I should use the new name, /dev/ide/host0/bus0/target1/lun0/cd. No, it does not work. Why? Let's look into /etc/modules.devfs. What a hell, there is a line `probeall /dev/ide ... ide-cd ...' , why doesn't it do what I want? Hmm, right, it cannot. Because /dev/ide already exists. It was created by the in-kernel IDE driver! If *all* IDE drivers were modules, then indeed, lookup to /dev/ide would load them all. But once some of them are in the kernel (or loaded by other means), there is no such effect. Right? I can load ide-cd using /dev/cdroms (it does not exist upon boot). But this works just because I have only one CD-ROM. If I had two, and one of the drivers was already loaded, then the second one would be not (auto)loadable at all. Or it seems so. And this method probes for all cdroms, thus loading a lot of modules (including SCSI), and I definitely don't want this. What can be done: adding a line `alias /dev/ide/*/cd ide-cd' in /etc/modules.conf makes the system load the module when the "canonical" device name is referenced. This is the Right Thing, and this is what devfs is for. I think such alias(es) should be in modules.devfs, or built into modprobe. Or maybe the right place for this is the kernel itself? Can devfs load modules without devfsd? But I still don't have my /dev/hdb! Well, it appears there as soon as ide-cd is loaded, but I don't know how to make it work "by lookup". Yes I can do `alias /dev/hdb ide-cd', but this assumes that /dev/hdb is always a CD-ROM. The problem is that there is no magical device like the old /dev/hdb, referring to "whatever sitting at the primary slave IDE". Maybe there should be nodes /dev/ide/.../lun0/disc for all IDE devices, not only hard discs? These could belong to the base IDE driver (ide-probe-mod?) and work like the old /dev/hdX. Then `/dev/ide/.../cd' could be a symlink to `disc'. And there might be a symlink `/dev/ide/.../hd' if the device is a hard disc. So one could refer to a device "of unknown type", or of a specific type (hd/cd/whatever) if desired. Okay, if you are still reading, here is the summary. 0) Devfs is a good thing. Really. 1) The "probeall" lines in modules.devfsd are bad - because the effect is inpredictable. More generally, loading modules by lookup should not load anything beyond the module providing the referenced node. 2) The default configuration (maybe any configuration) should have aliases for the kernel names (like /dev/ide/*/cd -> ide-cd). 3) If a driver can load modules itself, devfs should cooperate. Not everything can be done via devfsd. With best regards, Sergei P.S. It would be nice to mention in the FAQ that non-devfs modules do not work with devfs kernels. From owner-devfs@oss.sgi.com Wed Jul 11 01:36:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6B8a8W29088 for devfs-outgoing; Wed, 11 Jul 2001 01:36:08 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6B8a5V29079 for ; Wed, 11 Jul 2001 01:36:05 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f66KJxP00393; Fri, 6 Jul 2001 14:19:59 -0600 Date: Fri, 6 Jul 2001 14:19:59 -0600 Message-Id: <200107062019.f66KJxP00393@mobilix.ras.ucalgary.ca> From: Richard Gooch To: menion@fmtc.com Cc: devfs Subject: Re: PTS/? with incorrect ownership. In-Reply-To: <3B44CC4B.7010300@mindless.com> References: <3B44CC4B.7010300@mindless.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Joshua M. Schmidlkofer writes: > This is a multi-part message in MIME format. Yuk! MIME! > I am using UNIX98 PTY's, and using strictly devfs to manage the > 'devpts'. [a.k.a. no devpts fs support in my kernel]. For some reason, > under X I am experiencing a semi-random but frequent inability to start > terms of any kind. I have been trying to narrow the problem down, > however, I am not having good success. I added an event to devfsd that > executed a script....: > > 'REGISTER pts/.* EXECUTE /bin/logperms.sh' > 'UNREGISTER pts/.* EXECUTE /bin/logperms.sh' > > And I found that the files are being created w/incorrect > ownership. I started parsing through kernel code, examining > char/pty.c, char/tty_io.c, and devfs/base.c. I can follow the path > of execution, but I fail to see where the ownership could be > mistaken. As I started to try and read it, it came upon me that I > was going to have to learn about process management in the > kernel. This seems a bit of a steep climb from the hole that I am > in. [esp. when I can't open any new terminal. *laugh*]. Hm. Try changing fs/devfs/base.c:devfs_register() to use current->fsuid instead of current->uid (and similarly for gid), and recompile your kernel. I bet your xterm is using setfsuid(2) because it still has root privileges. Another test you can do is remove suid-root from the xterm binary. If it's using Unix98 PTYs, I don't see why it needs root access anyway. > Here are the symptoms: > > _SOMETIMES_ terminals will start properly, and when they do, I will > be able to open 5 or 6 or maybe even 10, but eventually the system > will halt opening new terminals. If I try to open a new one, then it > immediatly dies. If I start it from within an open one [i.e. rxvt&] > I get a message: 'unable to open slave pty'. I read through rxvt to > that point, and the code indicates that an open of /dev/pts/[??] > failed. Using the REGISTER event, I was able to see that the device > had an improper ownership. Further examination of the code SEEMED to > indicate that devfs _should_ have the device properly set before > notifying devfsd.... Actually, devfs will wait for devfsd to finish processing an event. Devfsd and all its children have special access to the filesystem. So if you were to have an action which logged the permissions, and then you have a PERMISSIONS action, the logging programme will see the original permissions before they are changed by PERMISSIONS. However, I don't think that is relevant to your problem. Anyway, I'm on holidays, so don't expect speedy followup responses. Good luck, and please let me know how it goes. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Wed Jul 11 07:05:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BE5gB30781 for devfs-outgoing; Wed, 11 Jul 2001 07:05:42 -0700 Received: from odin.oce.srci.oce.int ([208.187.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BE5dV30777 for ; Wed, 11 Jul 2001 07:05:40 -0700 Received: from mindless.com (widmers.oce.srci.oce.int [10.2.1.34]) by odin.oce.srci.oce.int; Wed, 11 Jul 2001 08:05:33 -0600 Message-ID: <3B4C5CB7.5080503@mindless.com> Date: Wed, 11 Jul 2001 08:03:35 -0600 From: "Joshua M. Schmidlkofer" Reply-To: menion@fmtc.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010710 X-Accept-Language: en-us MIME-Version: 1.0 To: Richard Gooch , devfs Subject: Re: PTS/? with incorrect ownership. References: <3B44CC4B.7010300@mindless.com> <200107062019.f66KJxP00393@mobilix.ras.ucalgary.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk > > > >Yuk! MIME! > Sorry about that.... >Hm. Try changing fs/devfs/base.c:devfs_register() to use >current->fsuid instead of current->uid (and similarly for gid), and >recompile your kernel. I bet your xterm is using setfsuid(2) because >it still has root privileges. > >Another test you can do is remove suid-root from the xterm binary. If > >it's using Unix98 PTYs, I don't see why it needs root access anyway. > I will try this, but I wanted to let you know that xterm is _not_ suid. konsole is not, but another bin called 'konsole_grantpty' [hmm. wonder what that could be doing *jk*] IS suid. rxvt is not. However, I don't know that much about KDE, etc. So I have no idea what the init processes are doing. kde_init runs everything, perhaps there are some changes going on underneath? >Actually, devfs will wait for devfsd to finish processing an event. >Devfsd and all its children have special access to the filesystem. So >if you were to have an action which logged the permissions, and then >you have a PERMISSIONS action, the logging programme will see the >original permissions before they are changed by PERMISSIONS. However, >I don't think that is relevant to your problem. > I meant that I suppose that before devfsd started its work, devfs had set the permissions. i.e. current->uid Before devfsd ran it's configuration.. I have not studied it all that much.. Thanks for the tip! joshua From owner-devfs@oss.sgi.com Wed Jul 11 08:36:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BFaDc10336 for devfs-outgoing; Wed, 11 Jul 2001 08:36:13 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BFaBV10333 for ; Wed, 11 Jul 2001 08:36:12 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6BFZbp09425; Wed, 11 Jul 2001 09:35:37 -0600 Date: Wed, 11 Jul 2001 09:35:37 -0600 Message-Id: <200107111535.f6BFZbp09425@mobilix.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@mobilix.ras.ucalgary.ca Subject: [PATCH] devfs v182 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 182 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz NOTE: this is an important fix for people with renumbering devices in /dev/discs or /dev/cdroms. Please test and report results to me. This is against 2.4.7-pre6. Highlights of this release: - Created and - Removed broken devnum allocation and use - Fixed old devnum leak by calling new - Created - Fixed number leak for /dev/cdroms/cdrom%d - Fixed number leak for /dev/discs/disc%d Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu Jul 12 12:15:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CJF3e29158 for devfs-outgoing; Thu, 12 Jul 2001 12:15:03 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CJF1V29143 for ; Thu, 12 Jul 2001 12:15:01 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.30 #1) id 15KlvJ-000665-00 for devfs@oss.sgi.com; Thu, 12 Jul 2001 12:14:54 -0700 Received: from [192.168.170.107] (helo=kevin) by jeeves.kpf.internal with smtp (Exim 3.30 #1) id 15KlrL-0000Xd-00 for devfs@oss.sgi.com; Thu, 12 Jul 2001 12:10:47 -0700 Message-ID: <000f01c10b07$28d1f6d0$6baaa8c0@kevin> From: "Kevin P. Fleming" To: Subject: first report for patch 182 Date: Thu, 12 Jul 2001 12:16:31 -0700 Organization: LSG, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-devfs@oss.sgi.com Precedence: bulk I am running 2.4.7-pre6 plus devfs patch v182 on two systems here, no problems so far. one has two cd rom devices on two different interfaces, the other has only one. both seem to be fine, even with ide-cd being unloaded/reload (/dev/cdroms contains proper entries at all times, it appears). From owner-devfs@oss.sgi.com Mon Jul 16 21:29:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H4TMa08235 for devfs-outgoing; Mon, 16 Jul 2001 21:29:22 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H4TKV08232 for ; Mon, 16 Jul 2001 21:29:20 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.30 #1) id 15MMTv-0004g1-00 for devfs@oss.sgi.com; Mon, 16 Jul 2001 21:29:12 -0700 Received: from [192.168.170.107] (helo=kevin) by jeeves.kpf.internal with smtp (Exim 3.30 #1) id 15MM8L-0000FB-00 for devfs@oss.sgi.com; Mon, 16 Jul 2001 21:06:53 -0700 Message-ID: <000901c10e76$c8ee6140$6baaa8c0@kevin> From: "Kevin P. Fleming" To: Subject: Userspace application check for devfs in use? Date: Mon, 16 Jul 2001 21:13:08 -0700 Organization: LSG, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-devfs@oss.sgi.com Precedence: bulk What is the proper (documented, recommended, whatever) method for a userspace application to check if the /dev filesystem is coming from devfs or not? I am modifying a tunneling application to use new-style /dev paths if devfs is in use, but it needs to know... Right now I'm just relying on a stat() of /dev/.devfsd returning without an error if devfs is mounted on /dev, but that may not be optimal (or future-proof). Any other suggestions? From owner-devfs@oss.sgi.com Mon Jul 16 23:41:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H6fp310117 for devfs-outgoing; Mon, 16 Jul 2001 23:41:51 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H6fnV10114 for ; Mon, 16 Jul 2001 23:41:49 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6H6fhr04305; Tue, 17 Jul 2001 00:41:43 -0600 Date: Tue, 17 Jul 2001 00:41:43 -0600 Message-Id: <200107170641.f6H6fhr04305@mobilix.ras.ucalgary.ca> From: Richard Gooch To: "Kevin P. Fleming" Cc: Subject: Re: Userspace application check for devfs in use? In-Reply-To: <000901c10e76$c8ee6140$6baaa8c0@kevin> References: <000901c10e76$c8ee6140$6baaa8c0@kevin> Sender: owner-devfs@oss.sgi.com Precedence: bulk Kevin P. Fleming writes: > What is the proper (documented, recommended, whatever) method for a > userspace application to check if the /dev filesystem is coming from devfs > or not? I am modifying a tunneling application to use new-style /dev paths > if devfs is in use, but it needs to know... > > Right now I'm just relying on a stat() of /dev/.devfsd returning > without an error if devfs is mounted on /dev, but that may not be > optimal (or future-proof). Any other suggestions? That *is* the correct method. But don't test for filetype. Just existence. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jul 16 23:48:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H6m8m10295 for devfs-outgoing; Mon, 16 Jul 2001 23:48:08 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H6m6V10291 for ; Mon, 16 Jul 2001 23:48:06 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6H53cW00368; Mon, 16 Jul 2001 23:03:38 -0600 Date: Mon, 16 Jul 2001 23:03:38 -0600 Message-Id: <200107170503.f6H53cW00368@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Sergei Ivanov Cc: Subject: Re: autoloading modules In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Sergei Ivanov writes: [Sorry for the delay in responding. I'm on holidays. Still.] > I just tried devfs for the first time. After fixing a number of > configuration issues, I found one that looks like a design problem > in devfs (of course, given my poor knowledge of it). > > I am using kernel 2.4.6, glibc-2.2.3 and devfsd-1.3.11. > The machine has a disc and a CD-ROM, used to be /dev/hda and /dev/hdb. > The disc driver is in the kernel, and CD-ROM support is in modules. > > Without devfs, I have /dev/hda and /dev/hdb. When /dev/hdb is accessed, > ide-cd module gets loaded. I don't know how this happens, probably the > kernel uses the results of IDE probe to find out which module to load. > > With devfs, there is no /dev/hdb. This is ok, devfsd is supposed to > manage it. (And it does so with some other devices - e.g. /dev/ttyS1 > works though the serial driver is modular.) But not so with ide-cd. > It is not autoloaded when /dev/hdb is referenced. > > Well, /dev/hdb is an old name, maybe I should use the new name, > /dev/ide/host0/bus0/target1/lun0/cd. No, it does not work. Why? > Let's look into /etc/modules.devfs. What a hell, there is a line > `probeall /dev/ide ... ide-cd ...' , > why doesn't it do what I want? Hmm, right, it cannot. Because /dev/ide > already exists. It was created by the in-kernel IDE driver! Ah. > If *all* IDE drivers were modules, then indeed, lookup to /dev/ide > would load them all. But once some of them are in the kernel > (or loaded by other means), there is no such effect. Right? > > I can load ide-cd using /dev/cdroms (it does not exist upon boot). > But this works just because I have only one CD-ROM. If I had two, > and one of the drivers was already loaded, then the second one would > be not (auto)loadable at all. Or it seems so. Ah. > And this method probes for all cdroms, thus loading a lot of modules > (including SCSI), and I definitely don't want this. > > What can be done: adding a line > `alias /dev/ide/*/cd ide-cd' > in /etc/modules.conf makes the system load the module when > the "canonical" device name is referenced. > > This is the Right Thing, and this is what devfs is for. > I think such alias(es) should be in modules.devfs, or built into modprobe. I've added that line to the modules.devfs file, plus a few others. > Or maybe the right place for this is the kernel itself? No. The core kernel cannot have any knowledge of device names. It's up to each driver to deal with names. And if a driver isn't loaded, then the name can't be given to an internal lookup function. > Can devfs load modules without devfsd? It used to call modprobe as a fallback, but that was pointless bloat. So I removed it. > But I still don't have my /dev/hdb! Well, it appears there as soon > as ide-cd is loaded, but I don't know how to make it work "by lookup". > Yes I can do `alias /dev/hdb ide-cd', but this assumes that /dev/hdb > is always a CD-ROM. The problem is that there is no magical device > like the old /dev/hdb, referring to "whatever sitting at the primary > slave IDE". Whatever /dev/hdb is will be host-dependent, and thus must be left to your personalised configuration files. > Maybe there should be nodes /dev/ide/.../lun0/disc for all IDE > devices, not only hard discs? These could belong to the base > IDE driver (ide-probe-mod?) and work like the old /dev/hdX. No. That's just too ugly to contemplate. > Then `/dev/ide/.../cd' could be a symlink to `disc'. > And there might be a symlink `/dev/ide/.../hd' if the device > is a hard disc. So one could refer to a device "of unknown type", > or of a specific type (hd/cd/whatever) if desired. Oh, the horrors. Remove half your RAM for a week as pennance. > Okay, if you are still reading, here is the summary. > > 0) Devfs is a good thing. Really. > > 1) The "probeall" lines in modules.devfsd are bad - because the effect > is inpredictable. More generally, loading modules by lookup should not > load anything beyond the module providing the referenced node. There isn't a way to do that. A single driver can support more than once device. > 2) The default configuration (maybe any configuration) should have aliases > for the kernel names (like /dev/ide/*/cd -> ide-cd). Yep. > 3) If a driver can load modules itself, devfs should cooperate. > Not everything can be done via devfsd. Devfsd is great: it can come with a default configration to work correctly on most systems, and it can be configured by the sysadmin as required. We don't want the kernel hard-wiring stuff. > P.S. It would be nice to mention in the FAQ that non-devfs modules > do not work with devfs kernels. It's the same as many, many other CONFIG options. Change the configuration, and modules are no longer compatible. This a basic FAQ entry and belongs elsewere. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Jul 17 07:24:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HEOWs20162 for devfs-outgoing; Tue, 17 Jul 2001 07:24:32 -0700 Received: from relay.ioffe.rssi.ru (root@relay.ioffe.rssi.ru [194.85.224.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HEOTV20159 for ; Tue, 17 Jul 2001 07:24:30 -0700 Received: from hilbert.pdmi.ras.ru (hilbert.pdmi.ras.ru [195.208.36.7]) by relay.ioffe.rssi.ru (8.9.1/8.9.1) with ESMTP id SAA19373 for ; Tue, 17 Jul 2001 18:24:24 +0400 (MSD) Received: from gauss.pdmi.ras.ru (gauss.pdmi.ras.ru [195.208.36.3]) by hilbert.pdmi.ras.ru (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA17082 for ; Tue, 17 Jul 2001 18:00:09 +0400 Received: from svivano.pdmi.ras.ru (uucp@localhost) by gauss.pdmi.ras.ru (8.8.8/8.8.8/Debian/GNU) with UUCP id SAA30340 for oss.sgi.com!devfs; Tue, 17 Jul 2001 18:24:10 +0400 Received: from localhost by svivano.pdmi.ras.ru with esmtp (Smail-3.2 1996-Jul-4 #1) id m15MVtA-000LnwC for ; Tue, 17 Jul 2001 18:31:52 +0400 (MSD) Date: Tue, 17 Jul 2001 18:31:52 +0400 (MSD) From: Sergei Ivanov X-X-Sender: To: Subject: Re: autoloading modules In-Reply-To: <200107170503.f6H53cW00368@mobilix.ras.ucalgary.ca> Message-ID: Organization: Steklov Institute of Mathematics at St.Petersburg MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, 16 Jul 2001, Richard Gooch wrote: > [...] > > But I still don't have my /dev/hdb! Well, it appears there as soon > > as ide-cd is loaded, but I don't know how to make it work "by lookup". > > Yes I can do `alias /dev/hdb ide-cd', but this assumes that /dev/hdb > > is always a CD-ROM. The problem is that there is no magical device > > like the old /dev/hdb, referring to "whatever sitting at the primary > > slave IDE". > > Whatever /dev/hdb is will be host-dependent, and thus must be left to > your personalised configuration files. Well, right, an "unknown" IDE device is of almost no use. Maybe only hdparm can reasonably deal with such a beast. And if this is a devfs issue at all, it's not the same device as "cdrom" or "disc". It's like "ttyS#" versus "ppp#". But an "IDE controller" device is probably not a thing that anyone wants to implement. > [...] > > 1) The "probeall" lines in modules.devfsd are bad - because the effect > > is inpredictable. More generally, loading modules by lookup should not > > load anything beyond the module providing the referenced node. > > There isn't a way to do that. A single driver can support more than > once device. I did not say "nothing except this node". I mean "a minimal subsystem in which this node exists". It's not a problem that one driver may add many files to /dev. The problem is when different drivers "provide" the same name - like /dev/ide or /dev/cdroms, and do not "own" it. Then one cannot rely on autoloading by this name - except the limited "make sure that at least one cdrom driver is loaded" (probe, but not all). In fact, it's just that more aliases are needed, like alias /dev/cdroms/cdrom? /dev/cdroms Then /dev/cdroms/cdrom1 works even if /dev/cdroms/cdrom0 already exists. I still don't like the "probeall" thing for probing too much (e.g. ZIP drive without media) but it's only a configuration option after all. BTW, it seems more logical for /dev/cdroms etc to always exist. There is a "driver" (inside devfs) whose job is to register cdrom devices. It "owns" the directory /dev/cdroms. Why not create this directory as soon as this "driver" is initialized? It would show the existence of the "registration system", not the existence of cdroms. And this subsystem could be optional, or even a module (if you want access via /dev/XXXs - load it, if not - why waste memory). And one more question/suggestion: why /dev/scsi and /dev/ide aren't like /dev/discs and /dev/cdroms? The numbering issues would go away if /dev/scsi/host# was a link to a driver-specific name, say /dev/scsi/aha1542/host0, or to /dev/all-drivers/ppa/host0. Or even /dev/scsi/host#/.../lun# might be a link to /dev/somewhere/ppa/parport0/disc0 if the ppa driver chooses so. Yet another bloat? > [...] > > 3) If a driver can load modules itself, devfs should cooperate. > > Not everything can be done via devfsd. > > Devfsd is great: it can come with a default configration to work > correctly on most systems, and it can be configured by the sysadmin as > required. We don't want the kernel hard-wiring stuff. Oh yes. The driver shows everything in /proc. A userspace program can scan /proc/ide and figure out which module is needed for the "unknown piece of hardware attached to that IDE interface". No real need for this stuff in the kernel. > > P.S. It would be nice to mention in the FAQ that non-devfs modules > > do not work with devfs kernels. > > It's the same as many, many other CONFIG options. Change the > configuration, and modules are no longer compatible. This a basic FAQ > entry and belongs elsewere. Sorry, this was new to me. Most options are mere add-ons, and things like SMP/non-SMP are "obvious". Even procfs only adds code to modules - they probably would work if compiled without it. But non-devfs modules break badly under a devfs kernel. Regards, Sergei From owner-devfs@oss.sgi.com Tue Jul 17 08:41:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HFfjW21817 for devfs-outgoing; Tue, 17 Jul 2001 08:41:45 -0700 Received: from odin.oce.srci.oce.int ([208.187.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HFfeV21813 for ; Tue, 17 Jul 2001 08:41:41 -0700 Received: from srci.iwpsd.org (widmers.oce.srci.oce.int [10.2.1.34]) by odin.oce.srci.oce.int; Tue, 17 Jul 2001 09:41:11 -0600 Message-ID: <3B545C11.7080302@srci.iwpsd.org> Date: Tue, 17 Jul 2001 09:38:57 -0600 From: "Joshua M. Schmidlkofer" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010715 X-Accept-Language: en-us MIME-Version: 1.0 To: Richard Gooch CC: menion@fmtc.com, devfs Subject: Re: PTS/? with incorrect ownership. References: <3B44CC4B.7010300@mindless.com> <200107062019.f66KJxP00393@mobilix.ras.ucalgary.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk > > > >Actually, devfs will wait for devfsd to finish processing an event. >Devfsd and all its children have special access to the filesystem. So >if you were to have an action which logged the permissions, and then >you have a PERMISSIONS action, the logging programme will see the >original permissions before they are changed by PERMISSIONS. However, >I don't think that is relevant to your problem. > >Anyway, I'm on holidays, so don't expect speedy followup >responses. Good luck, and please let me know how it goes. > > Regards, > > Richard.... >Permanent: rgooch@atnf.csiro.au >Current: rgooch@ras.ucalgary.ca > Richard, This is still happening wierder than ever. I don't know what to do. It is seemingly random, and I can at least open terms now, however, what I have to do it start so many in rapid succession that X & KDE bog down, and after 5 or 10 seconds about 15 will start to open, maybe four or five will survive, the rest will report 'unable to open slave pty .....' What can I do? Do I try a re-install? [I suspect the sames results in the end, but am willing to try]. ....... Maybe I will drop back to kernel 2.4.3, and see. thanks, joshua From owner-devfs@oss.sgi.com Tue Jul 17 09:26:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HGQt423253 for devfs-outgoing; Tue, 17 Jul 2001 09:26:55 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HGQsV23250 for ; Tue, 17 Jul 2001 09:26:54 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.30 #1) id 15MXgC-0005Kv-00; Tue, 17 Jul 2001 09:26:37 -0700 Received: from [192.168.170.107] (helo=kevin) by jeeves.kpf.internal with smtp (Exim 3.30 #1) id 15MXbr-0001GM-00; Tue, 17 Jul 2001 09:22:07 -0700 Message-ID: <004901c10edd$81069ca0$6baaa8c0@kevin> From: "Kevin P. Fleming" To: "Richard Gooch" Cc: References: <000901c10e76$c8ee6140$6baaa8c0@kevin> <200107170641.f6H6fhr04305@mobilix.ras.ucalgary.ca> Subject: Re: Userspace application check for devfs in use? Date: Tue, 17 Jul 2001 09:28:25 -0700 Organization: LSG, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-devfs@oss.sgi.com Precedence: bulk I originally _was_ going to check S_IFCHR on /dev/.devfsd, but forgot to finish typing the code and realized that just getting a non-error back from stat() would be sufficient. It works just fine, thanks for the info. ----- Original Message ----- From: "Richard Gooch" To: "Kevin P. Fleming" Cc: Sent: Monday, July 16, 2001 11:41 PM Subject: Re: Userspace application check for devfs in use? > Kevin P. Fleming writes: > > What is the proper (documented, recommended, whatever) method for a > > userspace application to check if the /dev filesystem is coming from devfs > > or not? I am modifying a tunneling application to use new-style /dev paths > > if devfs is in use, but it needs to know... > > > > Right now I'm just relying on a stat() of /dev/.devfsd returning > > without an error if devfs is mounted on /dev, but that may not be > > optimal (or future-proof). Any other suggestions? > > That *is* the correct method. But don't test for filetype. Just > existence. > > Regards, > > Richard.... > Permanent: rgooch@atnf.csiro.au > Current: rgooch@ras.ucalgary.ca > > > From owner-devfs@oss.sgi.com Sun Jul 22 22:03:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6N536I07835 for devfs-outgoing; Sun, 22 Jul 2001 22:03:06 -0700 Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6N535V07832 for ; Sun, 22 Jul 2001 22:03:05 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id f6N528g05023; Sun, 22 Jul 2001 23:02:08 -0600 Date: Sun, 22 Jul 2001 23:02:08 -0600 Message-Id: <200107230502.f6N528g05023@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v183 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 183 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.7. Highlights of this release: - Fixed bug in which could hang boot process Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jul 23 16:32:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NNWBb25983 for devfs-outgoing; Mon, 23 Jul 2001 16:32:11 -0700 Received: from sabi.co.UK (sabi.claranet.co.uk [212.126.138.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NNW2O25962 for ; Mon, 23 Jul 2001 16:32:03 -0700 Received: from localhost ([127.0.0.1] helo=home.sabi.co.UK ident=piercarl) by sabi.co.UK with smtp (Exim 3.16 #1) id 15Op73-0004e8-00 for devfs@OSS.SGI.com; Tue, 24 Jul 2001 00:27:45 +0100 Message-ID: <15196.45808.642654.342681@home.sabi.co.UK> Date: Tue, 24 Jul 2001 00:27:44 +0100 (BST) X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFbS AptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*SH< GG"+i\3#fp@@EeWZWBv;]LA5n1pS2VO%Vv[yH?kY'lEWr30WfIU?%>&spRGFL}{`bj1TaD^l/"[msn (/TH#THs{Hpj>)]f> Subject: a bug(?), some requests/suggestions X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: pg_mh@sabi.Clara.co.UK (Piercarlo Grandi) From: pg_mh@sabi.Clara.co.UK (Piercarlo Grandi) X-Disclaimer: This message contains only personal opinions Mime-Version: 1.0 (generated by tm-edit 1.6) Content-Type: multipart/mixed; boundary="Multipart_Tue_Jul_24_00:27:32_2001-1" Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk --Multipart_Tue_Jul_24_00:27:32_2001-1 Content-Type: text/plain; charset=US-ASCII This is mostly addressed to R.Gooch... I have started using 'devfs' quite recently (kernel 2.4.6), as I was scandalized by the number of entries in '/dev/' in most common distributions (my current SuSE 7.2 has over 2,000, Mandrake 7.1 had over 6,000), as you probably were when you decided to write 'devfs'. I think it's fine, but there are some small details... * One thing that did bite me is that entries under 'discs/', 'cdroms/' and 'tapes/' are not numbered, as suggested in the FAQ, consecutively starting from zero; right now I have 'cdrom0' and 'cdrom2', and at some point I had 'tape1' and 'tape5', for example. It seems to depend on whether the number of times the modules related to the devices have been loaded/unloaded. Now, I understand that every time a device driver modules is loaded it might choose for itself a higher number; in particular I understand that the SCSI HA modules choose a higher host number every time they are loaded (actually, do they in recent kernels?). But the numbers under 'discs/', 'cdroms/' and 'tapes/' should be strictly sequential starting with 0, as they are supposed to represent the ``nth'' device of that type. Also, the behaviour is somewhat inconsistent; for example I have a SCSI HA with a CD reader/writer and two tape units on it; my ATA setup is two discs and one CD/DVD reader. Just after booting I had the following devices: discs/0 discs/1 cdroms/0 cdroms/2 tapes/0 tapes/1 and the SCSI HA was listed under '/dev/scsi/host1' (which is right as I also have a virtual 'idescsi' HA for experimenting), which is listed under 'proc' as '/proc/scsi/sym53c8xx/1'. I have unloaded it and reloaded it a couple of times and now the situation is: ------------------------------------------------------------------------ # ls -ld discs/* cdroms/* tapes/* lr-xr-xr-x 1 root root 33 Jan 1 1970 cdroms/cdrom0 -> ../ide/host0/bus0/target1/lun0/cd lr-xr-xr-x 1 root root 34 Jan 1 1970 cdroms/cdrom2 -> ../scsi/host1/bus0/target3/lun0/cd lr-xr-xr-x 1 root root 30 Jan 1 1970 discs/disc0 -> ../ide/host0/bus0/target0/lun0 lr-xr-xr-x 1 root root 30 Jan 1 1970 discs/disc1 -> ../ide/host0/bus1/target0/lun0 lr-xr-xr-x 1 root root 31 Jan 1 1970 tapes/tape4 -> ../scsi/host1/bus0/target5/lun0 lr-xr-xr-x 1 root root 31 Jan 1 1970 tapes/tape5 -> ../scsi/host1/bus0/target6/lun0 ------------------------------------------------------------------------ which is somewhat bizarre: on every reload the tapes have increased their number by 2, but the cdrom numbers, even if oddly 0 and 2, have stayed the same. * Another possible bug: in the manuals page for 'devfsd' in the section 'CAVEATS' you mention the danger of using a ``devname'' like "cdrom", as it is not anchored by either/both '^' or '$'. However the sample 'devfsd.conf' and some of examples in the FAQ use similarly dangerous syntax. I have rewritten these REs in what I think is a safer/nicer way (down to details like replacing '.*' with '^.'), making essentially all ``devnames'' start with the '^' anchor, which I think should be the case. I have attached it. * The documentation is rather vague on what a regular expression is (there are _many_ flavours) and what kind of syntax the 'devfsd' configuration files can have; for example it is not clear if names with blanks or other special characters can be specified in '/etc/devfsd.conf'. * Against your advice :-), I do use entries like '/dev/modem', '/dev/tape', '/dev/cdrom'; I have attached a sample file that sets them up. I use 'COPY' for brevity. It would be nice to have built in 'SYMLINK', and 'UNLINK' actions, as the 'CFUNCTION' alternative seems to crash my 'devfsd'. I have appended the relevant bit of configuration. As you may note I have had to use the full Linus-style path to my CD-ROM and tape drives, as these are constant, while as noted above the 'cdroms/' and 'tapes/' entries seem to be changeable, which makes them nearly useless. * In any case I usually dislike symbolic links, for various practical and philosophical reasons; it would be nice if the 'MK{OLD,NEW}COMPAT' actions could optionally make hard links instead of symbolic links... This would also help in getting OLDCOMPAT or NEWCOMPAT names in '/proc/mounts' and other places instead of the very verbose kernel names. It seems to me that hard links should be really very easy to add; I just had a look at 'fs/devfs/base.c' and this seems indeed the case. Any subtle reasons why such a typical UNIX thingie is not supported? * It might be rather useful if 'devfs', whether or not was mounted as '/dev' or not, always mounted itself as '/proc/dev', as this would be both logically appropriate and easy to rely upon. * It would be nice if you kept a page (or may I could) with a list of applications that are use the old names, and possible workarounds. For example some versions of 'rxvt' has '/dev/ptyXX' hardcoded in, but some don't, and the rather equivalent 'aterm' uses '/dev/pts', so it is fine. 'diald' uses '/dev/pty%d' too, but not really, so it's fine. Also, it is possible to list the configuration bits that need to be changed to 'devfs'-ify them, and tips and tricks on figuring out which old-style entries one needs, e.g. using 'fuser -M /dev' or 'lsof +d /dev' or 'lsof +D /dev | sort -t/ +1a'. --Multipart_Tue_Jul_24_00:27:32_2001-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="devfsd.conf" Content-Transfer-Encoding: 7bit INCLUDE /etc/devfsd.local # Enable full compatibility mode for old device names. # You may comment these out if you don't use the old # device names. Make sure you know what you're doing! #REGISTER ^. MKOLDCOMPAT #UNREGISTER ^. RMOLDCOMPAT # You may comment out the above and uncomment the following # if you've configured your system to use the original "new" # devfs names or the really new names # 'agpgart' and 'psaux' for X11. REGISTER ^misc/ MKOLDCOMPAT UNREGISTER ^misc/ RMOLDCOMPAT # Floppy for '/etc/fstab'. REGISTER ^floppy/ MKOLDCOMPAT UNREGISTER ^floppy/ RMOLDCOMPAT # Ethertap, perhaps for 'diald'. #REGISTER ^netlink/ MKOLDCOMPAT #UNREGISTER ^netlink/ RMOLDCOMPAT # Virtual consoles for '/etc/inittab'. REGISTER ^(vc|vcc)/ MKOLDCOMPAT UNREGISTER ^(vc|vcc)/ RMOLDCOMPAT # Discs, CDROMs, tapes for '/etc/inittab', '/etc/fstab', '/etc/rc.d/' stuff. REGISTER ^(ide|scsi)/ MKOLDCOMPAT UNREGISTER ^(ide|scsi)/ RMOLDCOMPAT # Serial and parallel ports for '/etc/inittab', /etc/rc.d/' stuff. REGISTER ^(tts|printers)/ MKOLDCOMPAT UNREGISTER ^(tts|printers)/ RMOLDCOMPAT # These are useful if '/dev/pts/' is not available, # if it is, it is vastly preferable. #REGISTER ^pty/ MKOLDCOMPAT #UNREGISTER ^pty/ RMOLDCOMPAT # You may comment these out if you don't use the original "new" names #REGISTER ^. MKNEWCOMPAT #UNREGISTER ^. RMNEWCOMPAT # Enable module autoloading. You may comment this out if you don't use # autoloading #LOOKUP ^. MKOLDCOMPAT # Uh? Seems to be needed with 'mingetty' < 0.9.4b; check out (SuSE) # '/usr/share/doc/packages/devfsd/README' #LOOKUP ^vc/ EXECUTE /sbin/create_vc $devname # Enable module autoloading. You may comment this out # if you don't use autoloading #LOOKUP ^. MODLOAD # Permissions REGISTER ^(ide|scsi|md)/ PERMISSIONS root.disk 0660 REGISTER ^(floppy|loop)/ PERMISSIONS root.disk 0660 REGISTER ^snd/ PERMISSIONS root.audio 0660 REGISTER ^(fb|v4l)/ PERMISSIONS root.video 0660 REGISTER ^vc/ PERMISSIONS root.tty 0620 REGISTER ^vcc/ PERMISSIONS root.tty 0660 REGISTER ^(tts|cua)/ PERMISSIONS uucp.uucp 0660 REGISTER ^pts/ PERMISSIONS -1.tty 0620 REGISTER ^printers/ PERMISSIONS root.lp 0660 # ... to be completed ... # Uncomment these if you want permissions to be saved and restored #REGISTER ^pt[sy]/.* IGNORE #CHANGE ^pt[sy]/.* IGNORE #LOOKUP ^(pts/|pty|vc/|scsi/testdev) !COPY /devs/$devname $devpath #REGISTER ^(pts/|pty|vc/|scsi/testdev) !COPY /devs/$devname $devpath #CREATE ^(pts/|pty|vc/|scsi/testdev) !COPY $devpath /devs/$devname #CHANGE ^(pts/|pty|vc/|scsi/testdev) !COPY $devpath /devs/$devname --Multipart_Tue_Jul_24_00:27:32_2001-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="devfsd.local" Content-Transfer-Encoding: 7bit # Locally defined links # The following links may be established locally to conform to the # configuration of the system. This is merely a tabulation of existing # practice, and does not constitute a recommendation. REGISTER ^misc/psaux$ COPY $devpath mouse UNREGISTER ^misc/psaux$ EXECUTE rm mouse REGISTER ^tts/2$ COPY $devpath modem UNREGISTER ^tts/2$ EXECUTE rm modem REGISTER ^ide/host0/bus0/target0/lun0/disc$ COPY $devpath boot UNREGISTER ^ide/host0/bus0/target0/lun0/disc$ EXECUTE rm boot REGISTER ^scsi/host1/bus0/target5/lun0/mtn$ COPY $devpath tape UNREGISTER ^scsi/host1/bus0/target5/lun0/mtn$ EXECUTE rm tape REGISTER ^scsi/host1/bus0/target6/lun0/mtn$ COPY $devpath tape1 UNREGISTER ^scsi/host1/bus0/target6/lun0/mtn$ EXECUTE rm tape1 REGISTER ^ide/host0/bus0/target1/lun0/cd$ COPY $devpath cdrom UNREGISTER ^ide/host0/bus0/target1/lun0/cd$ EXECUTE rm cdrom REGISTER ^scsi/host1/bus0/target3/lun0/cd$ COPY $devpath cdrom1 UNREGISTER ^scsi/host1/bus0/target3/lun0/cd$ EXECUTE rm cdrom1 REGISTER ^scsi/host1/bus0/target3/lun0/generic$ COPY $devpath cdr UNREGISTER ^scsi/host1/bus0/target3/lun0/generic$ EXECUTE rm cdr REGISTER ^scsi/host1/bus0/target4/lun0/generic$ COPY $devpath scanner UNREGISTER ^scsi/host1/bus0/target4/lun0/generic$ EXECUTE rm scanner # Local configuration REGISTER ^fd[0-1] PERMISSIONS root.disk 0666 REGISTER ^tape[0-9]*$ PERMISSIONS root.disk 0666 REGISTER ^cdrom[0-9]*$ PERMISSIONS root.disk 0444 --Multipart_Tue_Jul_24_00:27:32_2001-1-- From owner-devfs@oss.sgi.com Mon Jul 23 18:56:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6O1uKA04056 for devfs-outgoing; Mon, 23 Jul 2001 18:56:20 -0700 Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6O1uIO04053 for ; Mon, 23 Jul 2001 18:56:18 -0700 Received: from nce2.hadiko.de (hadince2.hadiko.uni-karlsruhe.de [172.20.32.2]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1) id 15OrQm-0006pb-00; Tue, 24 Jul 2001 03:56:16 +0200 Received: from panorama.hadiko.de (hadii309.hadiko.uni-karlsruhe.de [172.20.44.69]) by nce2.hadiko.de (8.9.3/8.9.3) with SMTP id DAA17912 for ; Tue, 24 Jul 2001 03:56:14 +0200 (MET DST) Received: (qmail 18991 invoked from network); 24 Jul 2001 01:56:09 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Jul 2001 01:56:09 -0000 To: pg_mh@sabi.Clara.co.UK Cc: devfs@oss.sgi.com Subject: Re: a bug(?), some requests/suggestions From: Robert Siemer In-Reply-To: <15196.45808.642654.342681@home.sabi.co.UK> References: <15196.45808.642654.342681@home.sabi.co.UK> X-Mailer: Mew version 1.94b25 on Emacs 20.5 / Mule 4.0 (HANANOEN) Reply-To: Robert Siemer Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010724035608I.siemer@panorama.hadiko.de> Date: Tue, 24 Jul 2001 03:56:08 +0200 X-Dispatcher: imput version 990425(IM115) Lines: 21 Sender: owner-devfs@oss.sgi.com Precedence: bulk From: pg_mh@sabi.Clara.co.UK (Piercarlo Grandi) > * It might be rather useful if 'devfs', whether or not was mounted as > '/dev' or not, always mounted itself as '/proc/dev', as this would be > both logically appropriate and easy to rely upon. This makes no sense, as devfs is something what makes /proc/ obsolete. Richard told me to use devfs for drivers instead of procfs. And he is right here. It's ugly to use "files" in /proc/... So it would make more sense to use /dev/what-proc-was-some-times-ago/ Furthermore it is not a good thing to let devices apear where the admin doesn't want to. Devices should apear, where devfs is mounted to (maybe twice or more)... And it's not easy to rely on /proc for procfs and to find "dev" here. It's easier to rely on /dev as devfs. Bye, Robert From owner-devfs@oss.sgi.com Thu Jul 26 15:27:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6QMRVV32693 for devfs-outgoing; Thu, 26 Jul 2001 15:27:31 -0700 Received: from earth.ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6QMRTV32689 for ; Thu, 26 Jul 2001 15:27:29 -0700 Received: (from rjb@localhost) by earth.ayrnetworks.com (8.11.0/8.8.7) id f6QMQ9504925; Thu, 26 Jul 2001 15:26:09 -0700 Date: Thu, 26 Jul 2001 15:26:09 -0700 From: "Richard J. Broberg" Message-Id: <200107262226.f6QMQ9504925@earth.ayrnetworks.com> To: devfs@oss.sgi.com Subject: A patch to make it harder for drivers using devfs to crash the kernel Cc: ayrheads@ayrnetworks.com Sender: owner-devfs@oss.sgi.com Precedence: bulk While developing a driver for a hot pluggable device we wound up crashing the kernel when registering as a devfs device. A malformed driver has to try harder to crash the kernel when base.c has the following changes. The diff is against a 2.4 Hardhat mips distribution but 2.4.7 fs/devfs/base.c is similar. Richard Broberg diff -c -r1.1 base.c *** base.c 2001/03/30 23:58:41 1.1 --- base.c 2001/07/26 16:01:58 *************** *** 505,510 **** --- 505,511 ---- #include #include #include + #include /* for in_interrupt () */ #include #include *************** *** 522,527 **** --- 523,530 ---- #define INODE_TABLE_INC 250 #define FIRST_INODE 1 + #define KM_ALLOC_FLAG (in_interrupt() ? GFP_ATOMIC : GFP_KERNEL) + #define STRING_LENGTH 256 #define MIN_DEVNUM 36864 /* Use major numbers 144 */ *************** *** 771,777 **** { if ( ( table = kmalloc (sizeof *table * (fs_info.table_size + INODE_TABLE_INC), ! GFP_KERNEL) ) == NULL ) return NULL; fs_info.table_size += INODE_TABLE_INC; #ifdef CONFIG_DEVFS_DEBUG if (devfs_debug & DEBUG_I_CREATE) --- 774,780 ---- { if ( ( table = kmalloc (sizeof *table * (fs_info.table_size + INODE_TABLE_INC), ! KM_ALLOC_FLAG) ) == NULL ) return NULL; fs_info.table_size += INODE_TABLE_INC; #ifdef CONFIG_DEVFS_DEBUG if (devfs_debug & DEBUG_I_CREATE) *************** *** 786,792 **** fs_info.table = table; } if ( name && (namelen < 1) ) namelen = strlen (name); ! if ( ( new = kmalloc (sizeof *new + namelen, GFP_KERNEL) ) == NULL ) return NULL; /* Magic: this will set the ctime to zero, thus subsequent lookups will trigger the call to */ --- 789,795 ---- fs_info.table = table; } if ( name && (namelen < 1) ) namelen = strlen (name); ! if ( ( new = kmalloc (sizeof *new + namelen,KM_ALLOC_FLAG) ) == NULL ) return NULL; /* Magic: this will set the ctime to zero, thus subsequent lookups will trigger the call to */ *************** From owner-devfs@oss.sgi.com Thu Jul 26 19:41:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6R2fKC04367 for devfs-outgoing; Thu, 26 Jul 2001 19:41:20 -0700 Received: from mobilix.ras.ucalgary.ca ([209.226.93.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6R2fIV04362 for ; Thu, 26 Jul 2001 19:41:19 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6R2eow00912; Thu, 26 Jul 2001 22:40:50 -0400 Date: Thu, 26 Jul 2001 22:40:50 -0400 Message-Id: <200107270240.f6R2eow00912@mobilix.ras.ucalgary.ca> From: Richard Gooch To: "Richard J. Broberg" Cc: devfs@oss.sgi.com, ayrheads@ayrnetworks.com Subject: Re: A patch to make it harder for drivers using devfs to crash the kernel In-Reply-To: <200107262226.f6QMQ9504925@earth.ayrnetworks.com> References: <200107262226.f6QMQ9504925@earth.ayrnetworks.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Richard J. Broberg writes: > While developing a driver for a hot pluggable device > we wound up crashing the kernel when registering > as a devfs device. > > A malformed driver has to try harder to crash the kernel > when base.c has the following changes. But still not safe. You can't register entries outside a process context. You need to use a thread. Note that in time, the devfs core will be stripped down and will be a simple wrapper to the VFS, which also requires a process context. Since I know you'll never get Al Viro to accept interrupt-context safe dentry allocation, I'd urge you to switch to using a thread now :-) Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Jul 27 04:05:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RB5qf32508 for devfs-outgoing; Fri, 27 Jul 2001 04:05:52 -0700 Received: from nixpbe.pdb.sbs.de (nixpbe.pdb.sbs.de [192.109.2.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RB5oV32500 for ; Fri, 27 Jul 2001 04:05:50 -0700 Received: from trulli.pdb.fsc.net (ThisAddressDoesNotExist [172.25.96.20] (may be forged)) by nixpbe.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id f6RB5gH18923 for ; Fri, 27 Jul 2001 13:05:42 +0200 Received: from biker.pdb.fsc.net (biker.pdb.fsc.net [172.25.187.106]) by trulli.pdb.fsc.net (8.9.3/8.9.3) with ESMTP id NAA05682 for ; Fri, 27 Jul 2001 13:05:40 +0200 Received: from localhost (martin@localhost) by biker.pdb.fsc.net (8.11.0/8.11.0) with ESMTP id f6RB7AQ17884 for ; Fri, 27 Jul 2001 13:07:10 +0200 Date: Fri, 27 Jul 2001 13:07:10 +0200 (CEST) From: Martin Wilck To: devfs mailing list Subject: dsvfs & ide-floppy ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, I have the following problem with devfs: I have a LS120 floppy on the IDE controller as hda. If there is no floppy in the drive when the ide modules are loaded, no device node is created for the floppy by devfs. If a floppy is inserted later, devfs doesn't notice, so that there still is no device node. Consequently, the floppy cannot be accessed in any way even though the modules are loaded. All I can do is rmmod ide-floppy, insert the disk, and than reload the module. I think this is pretty uncomfortable for users. Is there any way to make devfs create a device node for the floppy even if no floppy is inserted at boot time? Martin -- Martin Wilck FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 From owner-devfs@oss.sgi.com Fri Jul 27 05:32:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RCWhH10576 for devfs-outgoing; Fri, 27 Jul 2001 05:32:43 -0700 Received: from mobilix.ras.ucalgary.ca ([209.226.93.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RCWfV10561 for ; Fri, 27 Jul 2001 05:32:41 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6RCWSw02538; Fri, 27 Jul 2001 08:32:28 -0400 Date: Fri, 27 Jul 2001 08:32:28 -0400 Message-Id: <200107271232.f6RCWSw02538@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Martin Wilck Cc: devfs mailing list Subject: Re: dsvfs & ide-floppy ? In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Martin Wilck writes: > > Hi, > > I have the following problem with devfs: > > I have a LS120 floppy on the IDE controller as hda. > > If there is no floppy in the drive when the ide modules are > loaded, no device node is created for the floppy by devfs. > If a floppy is inserted later, devfs doesn't notice, so that > there still is no device node. > Consequently, the floppy cannot be accessed in any way even though > the modules are loaded. > > All I can do is rmmod ide-floppy, > insert the disk, and than reload the module. I think this is > pretty uncomfortable for users. > > Is there any way to make devfs create a device node for the > floppy even if no floppy is inserted at boot time? Someone needs to write a patch to do this. Perhaps that can be you? BTW: if you load the driver with the floppy in, what device nodes are created? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Jul 27 08:22:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RFMGm13833 for devfs-outgoing; Fri, 27 Jul 2001 08:22:16 -0700 Received: from nixpbe.pdb.sbs.de (nixpbe.pdb.sbs.de [192.109.2.33]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RFMBV13830 for ; Fri, 27 Jul 2001 08:22:12 -0700 Received: from trulli.pdb.fsc.net (ThisAddressDoesNotExist [172.25.96.20] (may be forged)) by nixpbe.pdb.sbs.de (8.11.2/8.11.2) with ESMTP id f6RFLmH05979; Fri, 27 Jul 2001 17:21:48 +0200 Received: from biker.pdb.fsc.net (biker.pdb.fsc.net [172.25.187.106]) by trulli.pdb.fsc.net (8.9.3/8.9.3) with ESMTP id RAA29676; Fri, 27 Jul 2001 17:21:47 +0200 Received: from localhost (martin@localhost) by biker.pdb.fsc.net (8.11.0/8.11.0) with ESMTP id f6RFNFo18020; Fri, 27 Jul 2001 17:23:15 +0200 Date: Fri, 27 Jul 2001 17:23:15 +0200 (CEST) From: Martin Wilck To: Richard Gooch cc: Martin Wilck , devfs mailing list Subject: Re: dsvfs & ide-floppy ? In-Reply-To: <200107271232.f6RCWSw02538@mobilix.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk On Fri, 27 Jul 2001, Richard Gooch wrote: > Someone needs to write a patch to do this. Perhaps that can be you? I am trying to ... > BTW: if you load the driver with the floppy in, what device nodes are > created? A "disc" node in the respective controller/bus/target directory, and a /dev/hdX link. For some floppies, partition nodes are also created, but I doubt these are real (I see 2 partitions on a standard MS-DOS floppy ?). I found that ide-probe.c fails to set the "removable" flag of the device, and hoped that fixing this would solve the problem. Unfortunately that's not the case. It would be easier for me to create a patch if I knew what happens if "ide-cd" is loaded - in that case, devfs creates a node unconditionally even if no CD is inserted. Cheers, Martin -- Martin Wilck FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 From owner-devfs@oss.sgi.com Fri Jul 27 08:30:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RFUp614142 for devfs-outgoing; Fri, 27 Jul 2001 08:30:51 -0700 Received: from mobilix.ras.ucalgary.ca (congress144.linuxsymposium.org [209.151.18.144]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RFUoV14139 for ; Fri, 27 Jul 2001 08:30:50 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6RFUf803340; Fri, 27 Jul 2001 11:30:41 -0400 Date: Fri, 27 Jul 2001 11:30:41 -0400 Message-Id: <200107271530.f6RFUf803340@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Martin Wilck Cc: devfs mailing list Subject: Re: dsvfs & ide-floppy ? In-Reply-To: References: <200107271232.f6RCWSw02538@mobilix.ras.ucalgary.ca> Sender: owner-devfs@oss.sgi.com Precedence: bulk Martin Wilck writes: > On Fri, 27 Jul 2001, Richard Gooch wrote: > > > Someone needs to write a patch to do this. Perhaps that can be you? > I am trying to ... > > > BTW: if you load the driver with the floppy in, what device nodes are > > created? > > A "disc" node in the respective controller/bus/target directory, > and a /dev/hdX link. OK. Does it appear in /dev/discs ? > For some floppies, partition nodes are also created, but I doubt > these are real (I see 2 partitions on a standard MS-DOS floppy ?). I don't know. I don't have a LS120 to test with. > I found that ide-probe.c fails to set the "removable" flag of the > device, and hoped that fixing this would solve the > problem. Unfortunately that's not the case. Can you send a patch so I can see exactly what you did? > It would be easier for me to create a patch if I knew what happens > if "ide-cd" is loaded - in that case, devfs creates a node > unconditionally even if no CD is inserted. CD-ROMs don't have partitions. They are handled by the generic CD-ROM driver and not the gendisk driver. So for a CD-ROM you just get the device entry. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Jul 27 08:31:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RFV4I14169 for devfs-outgoing; Fri, 27 Jul 2001 08:31:04 -0700 Received: from energy.pdb.sbs.de (energy.pdb.sbs.de [192.109.2.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RFV3V14166 for ; Fri, 27 Jul 2001 08:31:03 -0700 Received: from trolli.pdb.fsc.net (ThisAddressDoesNotExist [172.25.97.20] (may be forged)) by energy.pdb.sbs.de (8.9.3/8.9.3) with ESMTP id RAA19704; Fri, 27 Jul 2001 17:30:50 +0200 Received: from biker.pdb.fsc.net (biker.pdb.fsc.net [172.25.187.106]) by trolli.pdb.fsc.net (8.9.3/8.9.3) with ESMTP id RAA13035; Fri, 27 Jul 2001 17:30:50 +0200 Received: from localhost (martin@localhost) by biker.pdb.fsc.net (8.11.0/8.11.0) with ESMTP id f6RFWJw18033; Fri, 27 Jul 2001 17:32:19 +0200 Date: Fri, 27 Jul 2001 17:32:19 +0200 (CEST) From: Martin Wilck To: Martin Wilck cc: Richard Gooch , devfs mailing list Subject: Re: dsvfs & ide-floppy ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk I just found out that it bis probably not a devfs problem at all: If I use ide-scsi rather than ide-floppy, the device is correctly detected as a removable device, and a node is created. Remains to find out what ide-scsi does ... Martin -- Martin Wilck FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 From owner-devfs@oss.sgi.com Fri Jul 27 08:41:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RFfWt14458 for devfs-outgoing; Fri, 27 Jul 2001 08:41:32 -0700 Received: from mobilix.ras.ucalgary.ca (congress144.linuxsymposium.org [209.151.18.144]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RFfVV14454 for ; Fri, 27 Jul 2001 08:41:31 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6RFfFe12463; Fri, 27 Jul 2001 11:41:15 -0400 Date: Fri, 27 Jul 2001 11:41:15 -0400 Message-Id: <200107271541.f6RFfFe12463@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Martin Wilck Cc: devfs mailing list Subject: Re: dsvfs & ide-floppy ? In-Reply-To: References: Sender: owner-devfs@oss.sgi.com Precedence: bulk Martin Wilck writes: > > I just found out that it bis probably not a devfs problem at all: If > I use ide-scsi rather than ide-floppy, the device is correctly > detected as a removable device, and a node is created. I know it's not a problem with the devfs core (i.e. the filesystem), it's a problem with the driver not advertising itself as a removable device properly. > Remains to find out what ide-scsi does ... Well, ide-disc and sd set the GENHD_FL_REMOVABLE flag, which fs/partitions/check.c convert to DEVFS_FL_REMOVABLE. I note that ide-floppy also sets GENHD_FL_REMOVABLE, but for some reason it doesn't make it to devfs_register(). You're going to need to do some tracing to figure this out. Make sure that devfs_register() is indeed getting the DEVFS_FL_REMOVABLE flag (shove in a printk). Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri Jul 27 09:22:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RGMIf15261 for devfs-outgoing; Fri, 27 Jul 2001 09:22:18 -0700 Received: from energy.pdb.sbs.de (energy.pdb.sbs.de [192.109.2.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RGMGV15258 for ; Fri, 27 Jul 2001 09:22:17 -0700 Received: from trolli.pdb.fsc.net (ThisAddressDoesNotExist [172.25.97.20] (may be forged)) by energy.pdb.sbs.de (8.9.3/8.9.3) with ESMTP id SAA25005; Fri, 27 Jul 2001 18:22:06 +0200 Received: from biker.pdb.fsc.net (biker.pdb.fsc.net [172.25.187.106]) by trolli.pdb.fsc.net (8.9.3/8.9.3) with ESMTP id SAA22131; Fri, 27 Jul 2001 18:22:06 +0200 Received: from localhost (martin@localhost) by biker.pdb.fsc.net (8.11.0/8.11.0) with ESMTP id f6RGNXN18079; Fri, 27 Jul 2001 18:23:33 +0200 Date: Fri, 27 Jul 2001 18:23:33 +0200 (CEST) From: Martin Wilck To: Richard Gooch cc: Martin Wilck , devfs mailing list Subject: Re: dsvfs & ide-floppy ? In-Reply-To: <200107271530.f6RFUf803340@mobilix.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk On Fri, 27 Jul 2001, Richard Gooch wrote: > > I found that ide-probe.c fails to set the "removable" flag of the > > device, and hoped that fixing this would solve the > > problem. Unfortunately that's not the case. > > Can you send a patch so I can see exactly what you did? It's rather trivial :-) --- 2.4.7/drivers/ide/ide-probe.c.orig Fri Jul 27 15:51:21 2001 +++ 2.4.7/drivers/ide/ide-probe.c Fri Jul 27 15:51:24 2001 @@ -122,6 +122,7 @@ printk("cdrom or floppy?, assuming "); if (drive->media != ide_cdrom) { printk ("FLOPPY"); + drive->removable = 1; break; } } Martin -- Martin Wilck FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 From owner-devfs@oss.sgi.com Fri Jul 27 12:33:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RJXSk20267 for devfs-outgoing; Fri, 27 Jul 2001 12:33:28 -0700 Received: from energy.pdb.sbs.de (energy.pdb.sbs.de [192.109.2.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RJXPV20263 for ; Fri, 27 Jul 2001 12:33:25 -0700 Received: from trolli.pdb.fsc.net (ThisAddressDoesNotExist [172.25.97.20] (may be forged)) by energy.pdb.sbs.de (8.9.3/8.9.3) with ESMTP id VAA03505; Fri, 27 Jul 2001 21:33:06 +0200 Received: from biker.pdb.fsc.net (biker.pdb.fsc.net [172.25.187.106]) by trolli.pdb.fsc.net (8.9.3/8.9.3) with ESMTP id VAA06453; Fri, 27 Jul 2001 21:33:07 +0200 Received: from localhost (martin@localhost) by biker.pdb.fsc.net (8.11.0/8.11.0) with ESMTP id f6RJYXT18159; Fri, 27 Jul 2001 21:34:33 +0200 Date: Fri, 27 Jul 2001 21:34:33 +0200 (CEST) From: Martin Wilck To: Richard Gooch cc: Martin Wilck , devfs mailing list , Linux Kernel mailing list Subject: [PATCH]: ide-floppy & devfs In-Reply-To: <200107271541.f6RFfFe12463@mobilix.ras.ucalgary.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, The following patch causes ide-floppy to register a disc even if no cartridge is in the drive, so that devfs creates nodes for the drive for later use. Without this patch, if devfs is used, no device node is ever created, and ide-floppy must be rmmoded and reloaded if a floppy is inserted into a drive that was empty at boot time. The reason is that grok_partitions() returns immediately if the device passed has a size parameter of 0, which was the case in ide-floppy with no cartrifge in the drive. The patch is against 2.4.7. It is somewhat a hack, perhaps somebody else finds a more elegant way to do it. But it makes sense that an empty drive does not return a capacity of 0, but the capacity of a standard media cartridge. Martin -- Martin Wilck FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 --- 2.4.7a/drivers/ide/ide-probe.c Sun Mar 18 18:25:02 2001 +++ 2.4.7/drivers/ide/ide-probe.c Fri Jul 27 23:01:49 2001 @@ -122,6 +122,7 @@ printk("cdrom or floppy?, assuming "); if (drive->media != ide_cdrom) { printk ("FLOPPY"); + drive->removable = 1; break; } } --- 2.4.7a/drivers/ide/ide-floppy.c Wed Jul 25 20:20:44 2001 +++ 2.4.7/drivers/ide/ide-floppy.c Fri Jul 27 23:00:38 2001 @@ -1279,7 +1279,15 @@ printk (KERN_NOTICE "%s: warning: non 512 bytes block size not fully supported\n", drive->name); rc = 0; } - } + } else if (!i && descriptor->dc == CAPACITY_NO_CARTRIDGE + && drive->removable && !(length % 512)) { + /* + Set these two so that idefloppy_capacity returns a positive value, + needed for devfs registration. + */ + floppy->blocks = blocks; + floppy->bs_factor = length / 512; + }; #if IDEFLOPPY_DEBUG_INFO if (!i) printk (KERN_INFO "Descriptor 0 Code: %d\n", descriptor->dc); printk (KERN_INFO "Descriptor %d: %dkB, %d blocks, %d sector size\n", i, blocks * length / 1024, blocks, length); From owner-devfs@oss.sgi.com Fri Jul 27 16:40:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RNePD15580 for devfs-outgoing; Fri, 27 Jul 2001 16:40:25 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RNeMV15565 for ; Fri, 27 Jul 2001 16:40:22 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.30 #1) id 15QHD9-00074k-00; Fri, 27 Jul 2001 16:40:04 -0700 Received: from [192.168.170.107] (helo=kevin) by jeeves.kpf.internal with smtp (Exim 3.30 #1) id 15QHCP-0004O8-00; Fri, 27 Jul 2001 16:39:17 -0700 Message-ID: <000701c116f5$8268a820$6baaa8c0@kevin> From: "Kevin P. Fleming" To: "Martin Wilck" , "Richard Gooch" Cc: "Martin Wilck" , "devfs mailing list" , "Linux Kernel mailing list" References: Subject: Re: [PATCH]: ide-floppy & devfs Date: Fri, 27 Jul 2001 16:40:25 -0700 Organization: LSG, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-devfs@oss.sgi.com Precedence: bulk Also note that I have already forwarded a patch to Richard to make the devfs nodes that get created when grok_partitions runs get removed when the media is removed and new media is validated (i.e. the partition nodes will stay in sync with the cartridge in the drive). ----- Original Message ----- From: "Martin Wilck" To: "Richard Gooch" Cc: "Martin Wilck" ; "devfs mailing list" ; "Linux Kernel mailing list" Sent: Friday, July 27, 2001 12:34 PM Subject: [PATCH]: ide-floppy & devfs > > Hi, > > The following patch causes ide-floppy to register a disc > even if no cartridge is in the drive, so that devfs creates > nodes for the drive for later use. Without this patch, > if devfs is used, no device node is ever created, and > ide-floppy must be rmmoded and reloaded if a floppy is inserted > into a drive that was empty at boot time. > > The reason is that grok_partitions() returns immediately if the > device passed has a size parameter of 0, which was the case > in ide-floppy with no cartrifge in the drive. > > The patch is against 2.4.7. > > It is somewhat a hack, perhaps somebody else finds a more elegant > way to do it. But it makes sense that an empty drive > does not return a capacity of 0, but the capacity of a standard media > cartridge. > > Martin > > -- > Martin Wilck > FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 > > --- 2.4.7a/drivers/ide/ide-probe.c Sun Mar 18 18:25:02 2001 > +++ 2.4.7/drivers/ide/ide-probe.c Fri Jul 27 23:01:49 2001 > @@ -122,6 +122,7 @@ > printk("cdrom or floppy?, assuming "); > if (drive->media != ide_cdrom) { > printk ("FLOPPY"); > + drive->removable = 1; > break; > } > } > --- 2.4.7a/drivers/ide/ide-floppy.c Wed Jul 25 20:20:44 2001 > +++ 2.4.7/drivers/ide/ide-floppy.c Fri Jul 27 23:00:38 2001 > @@ -1279,7 +1279,15 @@ > printk (KERN_NOTICE "%s: warning: non 512 bytes block size not fully supported\n", drive->name); > rc = 0; > } > - } > + } else if (!i && descriptor->dc == CAPACITY_NO_CARTRIDGE > + && drive->removable && !(length % 512)) { > + /* > + Set these two so that idefloppy_capacity returns a positive value, > + needed for devfs registration. > + */ > + floppy->blocks = blocks; > + floppy->bs_factor = length / 512; > + }; > #if IDEFLOPPY_DEBUG_INFO > if (!i) printk (KERN_INFO "Descriptor 0 Code: %d\n", descriptor->dc); > printk (KERN_INFO "Descriptor %d: %dkB, %d blocks, %d sector size\n", i, blocks * length / 1024, blocks, length); > > > > From owner-devfs@oss.sgi.com Sat Jul 28 05:17:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6SCH6022469 for devfs-outgoing; Sat, 28 Jul 2001 05:17:06 -0700 Received: from mobilix.ras.ucalgary.ca ([209.226.93.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6SCH4V22463 for ; Sat, 28 Jul 2001 05:17:05 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6SCFt716350; Sat, 28 Jul 2001 08:15:55 -0400 Date: Sat, 28 Jul 2001 08:15:55 -0400 Message-Id: <200107281215.f6SCFt716350@mobilix.ras.ucalgary.ca> From: Richard Gooch To: "Kevin P. Fleming" Cc: "Martin Wilck" , "devfs mailing list" , "Linux Kernel mailing list" Subject: Re: [PATCH]: ide-floppy & devfs In-Reply-To: <000701c116f5$8268a820$6baaa8c0@kevin> References: <000701c116f5$8268a820$6baaa8c0@kevin> Sender: owner-devfs@oss.sgi.com Precedence: bulk Kevin P. Fleming writes: > Also note that I have already forwarded a patch to Richard to make > the devfs nodes that get created when grok_partitions runs get > removed when the media is removed and new media is validated > (i.e. the partition nodes will stay in sync with the cartridge in > the drive). Are you saying that the two patch conflict? If not, can someone please verify that both together are safe? Or is your patch a superset? Either way, I can't really test these patches since I don't have removable media devices, so I'd prefer if someone else nurses this into Linus' tree (i.e. test it, call for testing and feed it to Linus until it goes in). Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sat Jul 28 09:23:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6SGNDZ10782 for devfs-outgoing; Sat, 28 Jul 2001 09:23:13 -0700 Received: from mail.labsysgrp.com (phnx1-blk2-hfc-0251-d1db10f1.rdc1.az.coxatwork.com [209.219.16.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6SGNCV10779 for ; Sat, 28 Jul 2001 09:23:12 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.30 #1) id 15QWrh-0007jM-00; Sat, 28 Jul 2001 09:22:58 -0700 Received: from [192.168.170.107] (helo=kevin) by jeeves.kpf.internal with smtp (Exim 3.30 #1) id 15QWqu-0005c2-00; Sat, 28 Jul 2001 09:22:08 -0700 Message-ID: <001001c11781$9db10a50$6baaa8c0@kevin> From: "Kevin P. Fleming" To: "Richard Gooch" Cc: "Martin Wilck" , "devfs mailing list" , "Linux Kernel mailing list" References: <000701c116f5$8268a820$6baaa8c0@kevin> <200107281215.f6SCFt716350@mobilix.ras.ucalgary.ca> Subject: Re: [PATCH]: ide-floppy & devfs Date: Sat, 28 Jul 2001 09:23:20 -0700 Organization: LSG, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-devfs@oss.sgi.com Precedence: bulk > Are you saying that the two patch conflict? If not, can someone please > verify that both together are safe? Or is your patch a superset? > Actually, the patches are complementary. However, my patch I won't be continuing to work on, as the entire way that partitions are read/validated/passed to devfs/etc will be changed in 2.5, and I've already forwarded this patch over to the maintainer of that code (whose name escapes my memory at the moment). So I'd say don't worry about it from the devfs end, you'll see the changes once 2.5 opens and these changes get merged in to that tree. From owner-devfs@oss.sgi.com Mon Jul 30 14:19:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ULJ7X12814 for devfs-outgoing; Mon, 30 Jul 2001 14:19:07 -0700 Received: from mobilix.ras.ucalgary.ca ([209.226.93.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ULJ0V12811 for ; Mon, 30 Jul 2001 14:19:05 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6ULITu00621; Mon, 30 Jul 2001 17:18:29 -0400 Date: Mon, 30 Jul 2001 17:18:29 -0400 Message-Id: <200107302118.f6ULITu00621@mobilix.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@mobilix.ras.ucalgary.ca Subject: devfsd-v1.3.12 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. I've just released version 1.3.12 of my devfsd (devfs daemon) at: http://www.atnf.csiro.au/~rgooch/linux/ Tarball directly available from: ftp://ftp.??.kernel.org/pub/linux/daemons/devfsd/devfsd.tar.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/daemons/devfsd/devfsd.tar.gz This works with devfs-patch-v130, kernel 2.3.46 and devfs-patch-v99.7 (or later). The main changes are: - Added compatibility entries for I2C devices. Thanks to Chris Rankin - Support multiple regular subexpressions. Thanks to Chris Rankin - Bug fix in MFUNCTION (bogus CFUNCTION could be called) - Bug fix for when execvp(3) failes (child did not exit) - Fixed potential buffer overrun problems. Thanks to Sebastian Krahmer - Added rpm.spec file. Thanks to Willian Stearns - Added devfsd.conf(5) man page. Thanks to Russell Coker - Included sample "mysymlink" shared object extension. Thanks to Russell Coker - Improved modules.devfs configuration file - Added PREFIX and MANDIR to GNUmakefile - Documentation updates. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jul 30 17:32:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V0WBh18124 for devfs-outgoing; Mon, 30 Jul 2001 17:32:11 -0700 Received: from mobilix.ras.ucalgary.ca ([209.226.93.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V0W3V18111 for ; Mon, 30 Jul 2001 17:32:03 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6V0UeJ13558; Mon, 30 Jul 2001 20:30:40 -0400 Date: Mon, 30 Jul 2001 20:30:40 -0400 Message-Id: <200107310030.f6V0UeJ13558@mobilix.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org Cc: devfs-announce-list@mobilix.ras.ucalgary.ca Subject: [RFT] Support for ~2144 SCSI discs Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Below is a patch that adds support for large numbers of SCSI discs (approximately 2144). I'd like people to try this out. I'm not doing my normal devfs-patch-v??? thing because this is completely untested (I'm away from my SCSI boxes), and I don't want to put a possibly FS-corrupting patch on my ftp archive. The code does compile and link, though. There are 3 cases I'd like to have tested: - people with 1 to 16 SCSI discs - people with 17 to 128 SCSI discs - people with >128 SCSI discs because each of these exercises a slightly different setup path. Please send success or failure reports to me. REMINDER: be careful with this patch. It could corrupt your FS. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca diff -urN linux-2.4.7/Documentation/Configure.help linux/Documentation/Configure.help --- linux-2.4.7/Documentation/Configure.help Thu Jul 19 20:48:15 2001 +++ linux/Documentation/Configure.help Mon Jul 23 01:19:24 2001 @@ -5410,6 +5410,17 @@ located on a SCSI disk. In this case, do not compile the driver for your SCSI host adapter (below) as a module either. +Many SCSI Discs support +CONFIG_SD_MANY + This allows you to support a very large number of SCSI discs + (approximately 2144). You will also need to set CONFIG_DEVFS_FS=y + later. This option may consume all unassigned block majors + (i.e. those which do not have an allocation in + Documentation/devices.txt). Enabling this will consume a few extra + kilobytes of kernel memory. + + Unless you have a large storage array, say N. + Extra SCSI Disks CONFIG_SD_EXTRA_DEVS This controls the amount of additional space allocated in tables for diff -urN linux-2.4.7/Documentation/filesystems/devfs/ChangeLog linux/Documentation/filesystems/devfs/ChangeLog --- linux-2.4.7/Documentation/filesystems/devfs/ChangeLog Wed Jul 11 17:55:41 2001 +++ linux/Documentation/filesystems/devfs/ChangeLog Mon Jul 30 19:13:00 2001 @@ -1675,3 +1675,13 @@ - Fixed number leak for /dev/cdroms/cdrom%d - Fixed number leak for /dev/discs/disc%d +=============================================================================== +Changes for patch v183 + +- Fixed bug in which could hang boot process +=============================================================================== +Changes for patch v184 + +- Support large numbers of SCSI discs (~2144) + +- Documentation typo fix for fs/devfs/util.c diff -urN linux-2.4.7/drivers/scsi/Config.in linux/drivers/scsi/Config.in --- linux-2.4.7/drivers/scsi/Config.in Thu Jul 5 14:28:16 2001 +++ linux/drivers/scsi/Config.in Mon Jul 23 01:19:47 2001 @@ -3,7 +3,8 @@ dep_tristate ' SCSI disk support' CONFIG_BLK_DEV_SD $CONFIG_SCSI if [ "$CONFIG_BLK_DEV_SD" != "n" ]; then - int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 + bool ' Many (~2144) SCSI discs support (requires devfs)' CONFIG_SD_MANY + int ' Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI diff -urN linux-2.4.7/drivers/scsi/hosts.h linux/drivers/scsi/hosts.h --- linux-2.4.7/drivers/scsi/hosts.h Fri Jul 20 15:55:46 2001 +++ linux/drivers/scsi/hosts.h Mon Jul 30 19:20:27 2001 @@ -506,9 +506,8 @@ const char * tag; struct module * module; /* Used for loadable modules */ unsigned char scsi_type; - unsigned int major; - unsigned int min_major; /* Minimum major in range. */ - unsigned int max_major; /* Maximum major in range. */ + unsigned int *majors; /* Array of majors used by driver */ + unsigned int num_majors; /* Number of majors used by driver */ unsigned int nr_dev; /* Number currently attached */ unsigned int dev_noticed; /* Number of devices detected. */ unsigned int dev_max; /* Current size of arrays */ diff -urN linux-2.4.7/drivers/scsi/osst.c linux/drivers/scsi/osst.c --- linux-2.4.7/drivers/scsi/osst.c Fri Jul 20 00:18:15 2001 +++ linux/drivers/scsi/osst.c Mon Jul 30 17:57:27 2001 @@ -160,7 +160,6 @@ name: "OnStream tape", tag: "osst", scsi_type: TYPE_TAPE, - major: OSST_MAJOR, detect: osst_detect, init: osst_init, attach: osst_attach, diff -urN linux-2.4.7/drivers/scsi/scsi_lib.c linux/drivers/scsi/scsi_lib.c --- linux-2.4.7/drivers/scsi/scsi_lib.c Thu Jul 19 23:48:04 2001 +++ linux/drivers/scsi/scsi_lib.c Mon Jul 30 17:52:35 2001 @@ -769,25 +769,10 @@ * Search for a block device driver that supports this * major. */ - if (spnt->blk && spnt->major == major) { - return spnt; - } - /* - * I am still not entirely satisfied with this solution, - * but it is good enough for now. Disks have a number of - * major numbers associated with them, the primary - * 8, which we test above, and a secondary range of 7 - * different consecutive major numbers. If this ever - * becomes insufficient, then we could add another function - * to the structure, and generalize this completely. - */ - if( spnt->min_major != 0 - && spnt->max_major != 0 - && major >= spnt->min_major - && major <= spnt->max_major ) - { - return spnt; - } + int i; + if (!spnt->blk || !spnt->majors) continue; + for (i = 0; i < spnt->num_majors; ++i) + if (spnt->majors[i] == major) return spnt; } return NULL; } diff -urN linux-2.4.7/drivers/scsi/sd.c linux/drivers/scsi/sd.c --- linux-2.4.7/drivers/scsi/sd.c Thu Jul 5 14:28:17 2001 +++ linux/drivers/scsi/sd.c Mon Jul 30 20:10:58 2001 @@ -28,6 +28,8 @@ * * Modified by Alex Davis * Fix problem where removable media could be ejected after sd_open. + * + * Modified by Richard Gooch rgooch@atnf.csiro.au to support >128 discs. */ #include @@ -65,7 +67,7 @@ * static const char RCSid[] = "$Header:"; */ -#define SD_MAJOR(i) (!(i) ? SCSI_DISK0_MAJOR : SCSI_DISK1_MAJOR-1+(i)) +#define SD_MAJOR(i) sd_template.majors[(i)] #define SCSI_DISKS_PER_MAJOR 16 #define SD_MAJOR_NUMBER(i) SD_MAJOR((i) >> 8) @@ -108,12 +110,6 @@ name:"disk", tag:"sd", scsi_type:TYPE_DISK, - major:SCSI_DISK0_MAJOR, - /* - * Secondary range of majors that this driver handles. - */ - min_major:SCSI_DISK1_MAJOR, - max_major:SCSI_DISK7_MAJOR, blk:1, detect:sd_detect, init:sd_init, @@ -123,6 +119,19 @@ init_command:sd_init_command, }; +#ifdef CONFIG_SD_MANY +static inline int sd_devnum_to_index (int devnum) +{ + int i, major = MAJOR (devnum); + + for (i = 0; i < sd_template.num_majors; ++i) + { + if (sd_template.majors[i] != major) continue; + return (i << 4) | (MINOR (i) >> 4); + } + return -ENODEV; +} +#endif static void rw_intr(Scsi_Cmnd * SCpnt); @@ -1043,6 +1052,41 @@ return i; } +static int sd_alloc_majors (void) +/* Allocate as many majors as required + */ +{ + int i, major; + + if ( ( sd_template.majors = + kmalloc (sizeof sd_template.majors * N_USED_SD_MAJORS, + GFP_ATOMIC) ) == NULL ) { + printk ("sd.c: unable to allocate major array\n"); + return -ENOMEM; + } + sd_template.majors[0] = SCSI_DISK0_MAJOR; + for (i = 1; (i < N_USED_SD_MAJORS) && (i = N_SD_PREASSIGNED_MAJORS) && (i < N_USED_SD_MAJORS); ++i) { + if ( ( major = devfs_alloc_major (DEVFS_SPECIAL_BLK) ) < 0 ) + break; + sd_template.majors[i] = major; + } + sd_template.dev_max = i * SCSI_DISKS_PER_MAJOR; + sd_template.num_majors = i; + return 0; +} /* End Function sd_alloc_majors */ + +static void sd_dealloc_majors (void) +/* Deallocate all the allocated majors + */ +{ + int i; + + for (i = sd_template.num_majors - 1; i >= N_SD_PREASSIGNED_MAJORS; --i) + devfs_dealloc_major (DEVFS_SPECIAL_BLK, sd_template.majors[i]); +} /* End Function sd_dealloc_majors */ + /* * The sd_init() function looks at all SCSI drives present, determines * their size, and reads partition table entries for them. @@ -1057,16 +1101,16 @@ if (sd_template.dev_noticed == 0) return 0; - if (!rscsi_disks) + if (!rscsi_disks) { sd_template.dev_max = sd_template.dev_noticed + SD_EXTRA_DEVS; - - if (sd_template.dev_max > N_SD_MAJORS * SCSI_DISKS_PER_MAJOR) - sd_template.dev_max = N_SD_MAJORS * SCSI_DISKS_PER_MAJOR; + if ( !sd_alloc_majors() ) return 1; + } if (!sd_registered) { for (i = 0; i < N_USED_SD_MAJORS; i++) { if (devfs_register_blkdev(SD_MAJOR(i), "sd", &sd_fops)) { printk("Unable to get major %d for SCSI disk\n", SD_MAJOR(i)); + sd_dealloc_majors(); return 1; } } @@ -1166,6 +1210,7 @@ for (i = 0; i < N_USED_SD_MAJORS; i++) { devfs_unregister_blkdev(SD_MAJOR(i), "sd"); } + sd_dealloc_majors(); sd_registered--; return 1; } @@ -1373,6 +1418,7 @@ scsi_unregister_module(MODULE_SCSI_DEV, &sd_template); + sd_dealloc_majors(); for (i = 0; i < N_USED_SD_MAJORS; i++) devfs_unregister_blkdev(SD_MAJOR(i), "sd"); diff -urN linux-2.4.7/drivers/scsi/sd.h linux/drivers/scsi/sd.h --- linux-2.4.7/drivers/scsi/sd.h Fri Jul 20 15:55:46 2001 +++ linux/drivers/scsi/sd.h Mon Jul 30 20:09:12 2001 @@ -42,10 +42,14 @@ */ extern kdev_t sd_find_target(void *host, int tgt); -#define N_SD_MAJORS 8 +#define N_SD_PREASSIGNED_MAJORS 8 +#ifdef CONFIG_SD_MANY +#define SD_PARTITION(i) ((sd_devnum_to_index((i)) << 4) | ((i)&0x0f)) +#else #define SD_MAJOR_MASK (N_SD_MAJORS - 1) #define SD_PARTITION(i) (((MAJOR(i) & SD_MAJOR_MASK) << 8) | (MINOR(i) & 255)) +#endif #endif diff -urN linux-2.4.7/drivers/scsi/sg.c linux/drivers/scsi/sg.c --- linux-2.4.7/drivers/scsi/sg.c Wed Jul 4 18:39:28 2001 +++ linux/drivers/scsi/sg.c Mon Jul 30 17:57:52 2001 @@ -123,7 +123,6 @@ { tag:"sg", scsi_type:0xff, - major:SCSI_GENERIC_MAJOR, detect:sg_detect, init:sg_init, finish:sg_finish, diff -urN linux-2.4.7/drivers/scsi/sr.c linux/drivers/scsi/sr.c --- linux-2.4.7/drivers/scsi/sr.c Thu Jul 5 14:28:17 2001 +++ linux/drivers/scsi/sr.c Mon Jul 30 17:59:33 2001 @@ -69,12 +69,15 @@ static int sr_init_command(Scsi_Cmnd *); +static unsigned int sr_major = SCSI_CDROM_MAJOR; + static struct Scsi_Device_Template sr_template = { name:"cdrom", tag:"sr", scsi_type:TYPE_ROM, - major:SCSI_CDROM_MAJOR, + majors:&sr_major, + num_majors:1, blk:1, detect:sr_detect, init:sr_init, diff -urN linux-2.4.7/drivers/scsi/st.c linux/drivers/scsi/st.c --- linux-2.4.7/drivers/scsi/st.c Fri Jul 20 00:16:32 2001 +++ linux/drivers/scsi/st.c Mon Jul 30 17:58:22 2001 @@ -160,7 +160,6 @@ name:"tape", tag:"st", scsi_type:TYPE_TAPE, - major:SCSI_TAPE_MAJOR, detect:st_detect, init:st_init, attach:st_attach, diff -urN linux-2.4.7/fs/devfs/base.c linux/fs/devfs/base.c --- linux-2.4.7/fs/devfs/base.c Wed Jul 11 17:55:41 2001 +++ linux/fs/devfs/base.c Mon Jul 30 19:10:41 2001 @@ -511,6 +511,9 @@ Removed broken devnum allocation and use . Fixed old devnum leak by calling new . v0.107 + 20010712 Richard Gooch + Fixed bug in which could hang boot process. + v0.108 */ #include #include @@ -543,7 +546,7 @@ #include #include -#define DEVFS_VERSION "0.107 (20010709)" +#define DEVFS_VERSION "0.108 (20010712)" #define DEVFS_NAME "devfs" @@ -1342,12 +1345,12 @@ return NULL; } } - de->u.fcb.autogen = 0; + de->u.fcb.autogen = FALSE; if ( S_ISCHR (mode) || S_ISBLK (mode) ) { de->u.fcb.u.device.major = major; de->u.fcb.u.device.minor = minor; - de->u.fcb.autogen = (devnum == NODEV) ? 0 : 1; + de->u.fcb.autogen = (devnum == NODEV) ? FALSE : TRUE; } else if ( S_ISREG (mode) ) de->u.fcb.u.file.size = 0; else @@ -1418,7 +1421,7 @@ MKDEV (de->u.fcb.u.device.major, de->u.fcb.u.device.minor) ); } - de->u.fcb.autogen = 0; + de->u.fcb.autogen = FALSE; return; } if (S_ISLNK (de->mode) && de->registered) @@ -2063,6 +2066,7 @@ {"show", OPTION_SHOW, &boot_options}, {"only", OPTION_ONLY, &boot_options}, {"mount", OPTION_MOUNT, &boot_options}, + {NULL, 0, NULL} }; while ( (*str != '\0') && !isspace (*str) ) @@ -2074,7 +2078,7 @@ invert = 1; str += 2; } - for (i = 0; i < sizeof (devfs_options_tab); i++) + for (i = 0; devfs_options_tab[i].name != NULL; i++) { int len = strlen (devfs_options_tab[i].name); diff -urN linux-2.4.7/fs/devfs/util.c linux/fs/devfs/util.c --- linux-2.4.7/fs/devfs/util.c Wed Jul 11 17:55:41 2001 +++ linux/fs/devfs/util.c Mon Jul 30 18:28:12 2001 @@ -39,6 +39,8 @@ Created and . 20010710 Richard Gooch Created . + 20010730 Richard Gooch + Documentation typo fix. */ #include #include @@ -214,7 +216,7 @@ /** * devfs_alloc_major - Allocate a major number. - * @type: The type of the major (DEVFS_SPECIAL_CHR or DEVFS_SPECIAL_BLOCK) + * @type: The type of the major (DEVFS_SPECIAL_CHR or DEVFS_SPECIAL_BLK) * Returns the allocated major, else -1 if none are available. * This routine is thread safe and does not block. @@ -238,7 +240,7 @@ /** * devfs_dealloc_major - Deallocate a major number. - * @type: The type of the major (DEVFS_SPECIAL_CHR or DEVFS_SPECIAL_BLOCK) + * @type: The type of the major (DEVFS_SPECIAL_CHR or DEVFS_SPECIAL_BLK) * @major: The major number. * This routine is thread safe and does not block. */ @@ -282,7 +284,7 @@ /** * devfs_alloc_devnum - Allocate a device number. - * @type: The type (DEVFS_SPECIAL_CHR or DEVFS_SPECIAL_BLOCK). + * @type: The type (DEVFS_SPECIAL_CHR or DEVFS_SPECIAL_BLK). * * Returns the allocated device number, else NODEV if none are available. * This routine is thread safe and may block. @@ -347,7 +349,7 @@ /** * devfs_dealloc_devnum - Dellocate a device number. - * @type: The type (DEVFS_SPECIAL_CHR or DEVFS_SPECIAL_BLOCK). + * @type: The type (DEVFS_SPECIAL_CHR or DEVFS_SPECIAL_BLK). * @devnum: The device number. * * This routine is thread safe and does not block. diff -urN linux-2.4.7/include/linux/blk.h linux/include/linux/blk.h --- linux-2.4.7/include/linux/blk.h Mon Jul 30 19:20:01 2001 +++ linux/include/linux/blk.h Mon Jul 30 20:05:18 2001 @@ -144,7 +144,11 @@ #define DEVICE_NAME "scsidisk" #define TIMEOUT_VALUE (2*HZ) +#ifdef CONFIG_SD_MANY +#define DEVICE_NR(device) sd_devnum_to_index((device)) +#else #define DEVICE_NR(device) (((MAJOR(device) & SD_MAJOR_MASK) << (8 - 4)) + (MINOR(device) >> 4)) +#endif /* Kludge to use the same number for both char and block major numbers */ #elif (MAJOR_NR == MD_MAJOR) && defined(MD_DRIVER) From owner-devfs@oss.sgi.com Mon Jul 30 17:57:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V0v5b19791 for devfs-outgoing; Mon, 30 Jul 2001 17:57:05 -0700 Received: from mobilix.ras.ucalgary.ca ([209.226.93.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V0v3V19788 for ; Mon, 30 Jul 2001 17:57:03 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6V0uMb13781; Mon, 30 Jul 2001 20:56:22 -0400 Date: Mon, 30 Jul 2001 20:56:22 -0400 Message-Id: <200107310056.f6V0uMb13781@mobilix.ras.ucalgary.ca> From: Richard Gooch To: pg_mh@sabi.Clara.co.UK (Piercarlo Grandi) Cc: Linux devfs Subject: Re: a bug(?), some requests/suggestions In-Reply-To: <15196.45808.642654.342681@home.sabi.co.UK> References: <15196.45808.642654.342681@home.sabi.co.UK> Sender: owner-devfs@oss.sgi.com Precedence: bulk Piercarlo Grandi writes: > I have started using 'devfs' quite recently (kernel 2.4.6), as I was > scandalized by the number of entries in '/dev/' in most common > distributions (my current SuSE 7.2 has over 2,000, Mandrake 7.1 had over > 6,000), as you probably were when you decided to write 'devfs'. > > I think it's fine, but there are some small details... > > * One thing that did bite me is that entries under 'discs/', 'cdroms/' > and 'tapes/' are not numbered, as suggested in the FAQ, consecutively > starting from zero; right now I have 'cdrom0' and 'cdrom2', and at > some point I had 'tape1' and 'tape5', for example. > > It seems to depend on whether the number of times the modules related > to the devices have been loaded/unloaded. Yes. Fixed in kernel 2.4.7. > * Another possible bug: in the manuals page for 'devfsd' in the section > 'CAVEATS' you mention the danger of using a ``devname'' like "cdrom", > as it is not anchored by either/both '^' or '$'. > > However the sample 'devfsd.conf' and some of examples in the FAQ use > similarly dangerous syntax. I have rewritten these REs in what I think > is a safer/nicer way (down to details like replacing '.*' with '^.'), > making essentially all ``devnames'' start with the '^' anchor, which I > think should be the case. I have attached it. Argh! You've changed it from a generic config file to something quite specific. Thus the patch is huge. If you want to send a patch to add anchors to the sample config file, don't include your own personalisations. That's no help to me. Grab a fresh copy of the sample config file and edit that. Patch rejected. > * The documentation is rather vague on what a regular expression is > (there are _many_ flavours) and what kind of syntax the 'devfsd' > configuration files can have; for example it is not clear if names > with blanks or other special characters can be specified in > '/etc/devfsd.conf'. Blanks are not allowed. Control characters are discouraged. > * Against your advice :-), I do use entries like '/dev/modem', > '/dev/tape', '/dev/cdrom'; I have attached a sample file that sets > them up. I use 'COPY' for brevity. It would be nice to have built in > 'SYMLINK', and 'UNLINK' actions, as the 'CFUNCTION' alternative seems > to crash my 'devfsd'. Try devfsd-v1.3.12. > * In any case I usually dislike symbolic links, for various practical > and philosophical reasons; it would be nice if the 'MK{OLD,NEW}COMPAT' > actions could optionally make hard links instead of symbolic links... > > This would also help in getting OLDCOMPAT or NEWCOMPAT names in > '/proc/mounts' and other places instead of the very verbose kernel > names. > > It seems to me that hard links should be really very easy to add; I > just had a look at 'fs/devfs/base.c' and this seems indeed the > case. Any subtle reasons why such a typical UNIX thingie is not > supported? Yes: it would make devfs a lot more complicated. Hard links are actually harder to add than you think. > * It might be rather useful if 'devfs', whether or not was mounted as > '/dev' or not, always mounted itself as '/proc/dev', as this would be > both logically appropriate and easy to rely upon. Nope. No more crap in /proc! > * It would be nice if you kept a page (or may I could) with a list of > applications that are use the old names, and possible workarounds. If you have time to track the applications that have been changed and those that still need to be changed, then please go ahead and write a WWW page. Send me the URL so I can point to it. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon Jul 30 19:09:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V293N22029 for devfs-outgoing; Mon, 30 Jul 2001 19:09:03 -0700 Received: from mobilix.ras.ucalgary.ca ([209.226.93.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V28xV22026 for ; Mon, 30 Jul 2001 19:09:00 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6V28pG14558; Mon, 30 Jul 2001 22:08:51 -0400 Date: Mon, 30 Jul 2001 22:08:51 -0400 Message-Id: <200107310208.f6V28pG14558@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Chris Martin Cc: devfs@oss.sgi.com Subject: Re: Running cdrecord with devfs In-Reply-To: References: <5.1.0.14.2.20010514133640.009d1480@pop.myrealbox.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Chris Martin writes: > I am running ROCK Linux 1.3.11. > > I have compiled 2.4.4 with the SCSI generic stuff to run cdrecord. > > I have the following lines in /etc/devfsd.conf > > LOOKUP .* MODLOAD > CREATE /dev/scsi/host0/bus0/target0/lun0/cd CFUNCTION GLOBAL symlink sg0 cd > > these lines (among others) in /etc/modules.conf (a scattergun > approach, I'm afraid) > > alias scsi_hostadapter ide-scsi > alias cdrom ide-scsi > alias sga ide-scsi > probeall scsi-hosts ide-scsi > > and the standard /etc/modules.devfs (3-JUL-2000) > > On booting, lsmod shows no modules loaded. > > On entering > > l /dev/scsi > > the info from loading the ide-scsi module is shown with > > Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 > > and > > /dev/scsi/host0/bus0/target0/lun0/cd > /dev/scsi/host0/bus0/target0/lun0/generic > > are both created but no sg0. > > /dev/cdrom is a symbolic link to /dev/cdroms/cdrom0 and > /dev/cdroms/cdrom0 is a symbolic link to > ../scsi/host0/bus0/target0/lun0/cd > > Running cdrecord -scanbus fails as it can't find /dev/sg0 (or > sg1...sg31, sga..sgz) > > However, manually putting in the symlink would be OK if I wasn't using > a CR-ROM for testing... > > Can you tell me what I am missing about CREATE? Read the man page more carefully. You probably want the REGISTER event. Also, you probably want to use the MKOLDCOMPAT action. The sample devfs.conf file that I ship sets up compatibility entries. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Jul 31 16:30:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VNU6p14598 for devfs-outgoing; Tue, 31 Jul 2001 16:30:06 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VNU3V14592 for ; Tue, 31 Jul 2001 16:30:04 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6VLF0r00459; Tue, 31 Jul 2001 15:15:00 -0600 Date: Tue, 31 Jul 2001 15:15:00 -0600 Message-Id: <200107312115.f6VLF0r00459@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Jurgen Botz Cc: tytso@mit.edu, devfs@oss.sgi.com Subject: Re: ttyS1, S2, etc... In-Reply-To: <200004130732.AAA17540@nova.botz.org> References: <200004130658.e3D6wHw06466@vindaloo.ras.ucalgary.ca> <200004130732.AAA17540@nova.botz.org> Sender: owner-devfs@oss.sgi.com Precedence: bulk [Still working backwards through my old email] Jurgen Botz writes: > Richard Gooch wrote: > > I don't see why you can't just have devfsd load the module when you > > attempt a lookup of /dev/ttyS.* or whatever. Then the existing rc > > scripts which do: > > # setserial /dev/ttyS0 ... > > # setserial /dev/ttyS1 ... > > # setserial /dev/ttyS2 ... > > # setserial /dev/ttyS3 ... > > Richard, you're missing the point. We aren't talking about the > system board serial ports, we're talking about additional serial > ports on dumb ISA multiport cards. Devfs will not create the > devices for these because the driver, whether module or compiled-in, > doesn't know they exist until serserial is called! You can > currently compile the serial driver with options to be able to > handle these cards, but the actual configuration (whether, how > many, what IRQ, etc.) is not compiled in and can't be auto-sensed. > > So like I said originally, there's a chicken-and-egg problem... > devfs can't create the device because it doesn't know the port > exists, and setserial can't tell the driver that the port exists > because there is no device on which to do the ioctls that are > used to pass this info to the kernel. > > The point is that because these boards can't be auto-sensed > we need to pass info to the kernel about the ports. Prior to > devfs using ioctls on the devices made the most sense. Now, > with devfs, the devices don't exist until we've talked to the > kernel. So we need to find another way to pass the info to > the kernel. module options and kernel command line are not > a good solution because it's too much info if there are a lot > of ports. OK, so in this (unhappy) case, what you can do is configure devfsd to do mknod(2) and setserial(8) upon LOOKUP. A simple script will work. Or, you can just do mknod(1) prior to setserial(8) in your boot script. Yet another approach is to configure devfsd to mknod(2) upon LOOKUP, leaving the setserial(8) step to your boot scripts. A fairly clean solution would be: LOOKUP ^tts/.*$ MODLOAD LOOKUP ^tts/.*$ EXECUTE /sbin/serial-helper $devpath #! /bin/sh # /sbin/serial-helper if [ ! -f $1 ]; then #minor= 64 + index (left as an exercise for the reader) mknod $1 c 4 $minor fi exit 0 # End Thus, the serial devices which are probed correctly by the driver need no extra work, and the rest have their device nodes created. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Jul 31 16:30:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VNUxs14620 for devfs-outgoing; Tue, 31 Jul 2001 16:30:59 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VNUuV14617 for ; Tue, 31 Jul 2001 16:30:56 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6VKrV200367; Tue, 31 Jul 2001 14:53:31 -0600 Date: Tue, 31 Jul 2001 14:53:31 -0600 Message-Id: <200107312053.f6VKrV200367@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Johannes Erdfelt Cc: devfs@oss.sgi.com Subject: Re: devfs and device name persistance In-Reply-To: <20000508230459.B1842@valinux.com> References: <20000508221945.A1842@valinux.com> <200005090534.e495YQ910398@vindaloo.ras.ucalgary.ca> <20000508230459.B1842@valinux.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk [Very late reply: I'm working backwards through my overflowing inbox] Johannes Erdfelt writes: > On Mon, May 08, 2000, Richard Gooch wrote: > > Johannes Erdfelt writes: > > > With more and more Hot Swap device busses becoming common, naming of devices > > > is starting to become a problem. > > > > > > As an example, I'll use 2 USB floppy drives. Since they are floppy drives, > > > the media and thusly filesystems can change frequently. > > [...] > > > The first problem is being able to differentiate between similar > > > devices. USB has the notion of a serial number, however not all > > > devices provide one. Most storage devices do however, which is the > > > reason I'm using floppies as my example. > > > > > > Now that we have a unique way of differentiating 2 seemingly identical > > > devices, our next problem is how to store this information. This is > > > where devfsd comes in. I'd like to use devfsd to track this information. > > > How it does this is not too important right now. > > > > > > The last problem is name space conflict. > > > > > > There may be a real device called /dev/floppy0. A possible solution > > > that has been discussed is to mount the devfs filesystem on /devices > > > (completely aribtrary name) and create symlinks between the virtual > > > names on /dev to the physical names on /devices. > > > > I think any move that promotes mounting devfs elsewhere is going to > > come back and hurt us in the future. /dev should be the only place > > that applications (and administrators) look for device files. As soon > > as we start seeing people (distributions) mounting devfs on /devfs, we > > will see applications looking in multiple places for device > > nodes. This will inevitably cause confusion, and once done, will be > > very hard to fix. > > > > And having a pile of symlinks doesn't really solve the namespace > > problem, because you can always come up with some name that will > > conflict. And besides, a /dev full of symlinks is going to be > > butt-ugly. > > > > I think the only solution to namespace conflicts is to admit that it > > is real and has to be dealt with firmly. This means coming up with a > > policy and "enforcing" it (i.e. various utilities follow that policy > > and if you try and change it and it breaks, you get to keep the > > pieces). > > > > However, it probably makes sense to put *all* USB devices under > > /dev/usb, just like the SCSI and IDE trees. > > Most people are interested in the function rather than the connection. > > Very similar to how devfs currently create a /dev/discs which has all of > the disks on the system. It's an abstracted directory of all disks > regardless of it's connection (scsi, ide, usb, etc) > > Why cannot this be managed by devfsd? I'd prefer the kernel manages device-type directories like /dev/cdroms. It's definately nicer for the root FS on such a device. And it's easier for the kernel to manage it. > It would be a win to move this to userspace versus the kernel where > it is now. You could make the same argument for /dev/discs and /dev/cdroms. In fact it's easier to let the kernel do it. > This has the added benefit of choosing names intelligently. I don't think device-type names should be chosen "intelligently". The simple numerical sequence is fine. If you want some other kind of name, then that can be managed by devfsd. But the kernel should provide a simple namespace you can rely on. > > > What I'd like to get is some opinions on this. I have a reservation > > > towards putting so much into devfsd. I fear it may become too > > > complicated. > > > > Also, I'd want to avoid "solutions" that are really only partial > > solutions. I think we should just bite the bullet on namespace policy. > > I'm not exactly sure I understand what you mean. Is there a current > problem you're referring to? I'm referring more to "solutions" like scsidev, which only solve part of the problem, and other alternatives proposed as a way of limping along so that devfs can be avoided at all costs. > > > Also, not all devices can be differentiated. However, we can do some > > > things. For instance, we can determine which port a device is > > > plugged into and create a topology tree. This way, we can > > > differentiate 2 mice. However, if the device is moved to another > > > port, the mouse would be "new". > > > > Yep. Not much to be done about that. > > Well, I'd like to offer it as an option to use that algorithm. Many > OS' currently do like Windows and BeOS. If you have an algorithm, then fine, create a new namespace. But we should still keep a simple kernel namespace. The kernel namespace will work fine for people with only 1 of each type of device, and will work without the need for devfsd. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue Jul 31 16:42:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VNgkP14835 for devfs-outgoing; Tue, 31 Jul 2001 16:42:46 -0700 Received: from mobilix.ras.ucalgary.ca (h-207-228-73-44.gen.cadvision.com [207.228.73.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VNgiV14832 for ; Tue, 31 Jul 2001 16:42:44 -0700 Received: (from rgooch@localhost) by mobilix.ras.ucalgary.ca (8.10.0/8.10.0) id f6VIxDN00956; Tue, 31 Jul 2001 12:59:13 -0600 Date: Tue, 31 Jul 2001 12:59:13 -0600 Message-Id: <200107311859.f6VIxDN00956@mobilix.ras.ucalgary.ca> From: Richard Gooch To: Meunier <0@pervalidus.net> Cc: devfs@oss.sgi.com Subject: Re: error calling: "symlink" in "GLOBAL" In-Reply-To: <20010408113044.I111@pervalidus.net> References: <20010406023231.W111@pervalidus> <200104080526.f385QU906141@mobilix.atnf.CSIRO.AU> <20010408113044.I111@pervalidus.net> Sender: owner-devfs@oss.sgi.com Precedence: bulk 0@pervalidus.net writes: > On Sun, Apr 08, 2001 at 03:26:30PM +1000, Richard Gooch wrote: > > 0@pervalidus.net writes: > > > Hi. I'm using > > > > > > #REGISTER vc/.* MKOLDCOMPAT > > > #UNREGISTER vc/.* RMOLDCOMPAT > > > > > > and want to create some symlinks instead. Using > > > > > > REGISTER vc/1 CFUNCTION GLOBAL symlink vc/1 tty1 > > > UNREGISTER vc/1 CFUNCTION GLOBAL unlink tty1 > > > > > > works but I get the following messages: > > > > > > Started device management daemon for /dev > > > error calling: "symlink" in "GLOBAL" > > > error calling: "symlink" in "GLOBAL" > > > error calling: "symlink" in "GLOBAL" > > > error calling: "symlink" in "GLOBAL" > > > error calling: "symlink" in "GLOBAL" > > > error calling: "symlink" in "GLOBAL" > > > error calling: "symlink" in "GLOBAL" > > > error calling: "symlink" in "GLOBAL" > > > error calling: "symlink" in "GLOBAL" > > > error calling: "symlink" in "GLOBAL" > > > > > > What's wrong ? I'm a bit confused about the devfsd man page > > > syntax for symlinks: > > > > > > REGISTER mydir/mydev CFUNCTION GLOBAL symlink $devname mydev > > > UNREGISTER mydir/mydev CFUNCTION GLOBAL unlink mydev > > > > What version of devfsd are you running? > > I'm using devfsd 1.3.11 on 2.4.3 Kernel. The problem may be due to your two lines: REGISTER vc/1 CFUNCTION GLOBAL symlink vc/1 tty1 UNREGISTER vc/1 CFUNCTION GLOBAL unlink tty1 It's possible that you're repeating the "symlink vc/1 tty1" action many times, because the "vc/1" regular expression will match "vc/10", "vc/11" and so on, as well as the intended "vc/1". You have a number of alternatives: REGISTER vc/1$ CFUNCTION GLOBAL symlink vc/1 tty1 UNREGISTER vc/1$ CFUNCTION GLOBAL unlink tty1 this will anchor the '1' at the end of the path. Or, much better to do this: REGISTER vc/1$ MKOLDCOMPAT UNREGISTER vc/1$ RMOLDCOMPAT which will use the recommended MKOLDCOMPAT and RMOLDCOMPAT actions. Even better is to just use: REGISTER vc/.* MKOLDCOMPAT UNREGISTER vc/.* RMOLDCOMPAT like the sample config file recommends. Why would you want to do anything else? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca