From owner-devfs@oss.sgi.com Thu May 2 18:51:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g431pGwJ025817 for ; Thu, 2 May 2002 18:51:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g431pFOY025816 for devfs-outgoing; Thu, 2 May 2002 18:51:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g431pBwJ025813 for ; Thu, 2 May 2002 18:51:13 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id E195692460 for ; Fri, 3 May 2002 11:51:34 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 5E61CCC8 for ; Fri, 3 May 2002 11:46:27 +1000 (EST) Content-Type: text/plain; charset="us-ascii" From: Russell Coker Reply-To: Russell Coker To: devfs@oss.sgi.com Subject: SE Linux and devfsd Date: Fri, 3 May 2002 11:46:27 +1000 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020503014627.5E61CCC8@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk The NSA have just made a new release of SE Linux, and my code for the SE Linux Devfsd module is included. -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-devfs@oss.sgi.com Fri May 3 16:06:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43N6NwJ032636 for ; Fri, 3 May 2002 16:06:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43N6NRB032634 for devfs-outgoing; Fri, 3 May 2002 16:06:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43N6GwJ032628 for ; Fri, 3 May 2002 16:06:17 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id C3B7292452; Sat, 4 May 2002 09:09:27 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 2EA48341A; Sat, 4 May 2002 09:07:49 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Matt Zimmerman , 145718@bugs.debian.org Subject: Re: Bug#145718: devfsd: invalid operand: 0000 Date: Sat, 4 May 2002 09:07:48 +1000 X-Mailer: KMail [version 1.3.2] References: <20020503184119.GA15110@alcor.net> In-Reply-To: <20020503184119.GA15110@alcor.net> Cc: devfs@oss.sgi.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020503230749.2EA48341A@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Sat, 4 May 2002 04:41, you wrote: > I have a system which periodically issues this error, killing devfsd: > > invalid operand: 0000 > CPU: 1 > EIP: 0010:[] Not tainted Firstly, I'm not sure that the Debian BTS is an appropriate forum for such bugs. Secondly it's definately not a devfsd issue, naturally if your kernel is correctly functioning then nothing devfsd will do will cause a panic. > Details vary, of course, but the stack trace is pretty much the same > always. The system is running a custom 2.4.17 kernel, the only substantial > differences from the stock 686-smp kernel are CONFIG_HIGHMEM4G=y and > CONFIG_MPENTIUMIII=y. > > I am about to upgrade to a similar 2.4.18 kernel, and will report as to > whether I see this happen again (could take a few days). Have you applied any devfs patches to 2.4.17? I never got a 2.4.17 kernel to do devfs without a patch, and even with a patch there were some issues. I recommend using 2.4.16 or 2.4.18 for devfs as both of them worked for me. Russell Coker PS I would like to re-assign this to your kernel package, or close it. PPS I'll forward your bug report to devfs@oss.sgi.com From owner-devfs@oss.sgi.com Fri May 3 16:06:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43N6UwJ032647 for ; Fri, 3 May 2002 16:06:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43N6UQI032646 for devfs-outgoing; Fri, 3 May 2002 16:06:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43N6JwJ032630 for ; Fri, 3 May 2002 16:06:20 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 8A9D292460 for ; Sat, 4 May 2002 09:09:30 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 8B1B03441 for ; Sat, 4 May 2002 09:07:53 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: devfs@oss.sgi.com Subject: Fwd: Bug#145718: devfsd: invalid operand: 0000 Date: Sat, 4 May 2002 09:07:53 +1000 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020503230753.8B1B03441@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk ---------- Forwarded Message ---------- Subject: Bug#145718: devfsd: invalid operand: 0000 Date: Fri, 3 May 2002 14:41:19 -0400 From: Matt Zimmerman To: Debian Bug Tracking System Package: devfsd Version: 1.3.25-6 Severity: normal I have a system which periodically issues this error, killing devfsd: invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 5a5a5a00 ebx: d907aaa0 ecx: c34d3260 edx: d907aad0 esi: c34d3260 edi: f724b620 ebp: d907aaa0 esp: cf6a7f18 ds: 0018 es: 0018 ss: 0018 Process devfsd (pid: 22189, stackpage=cf6a7000) Stack: f705f9e0 c015e67e d907aaa0 c34d3260 d907aaa0 00000000 cf6a7fa4 f724d940 c013ea2e d907aaa0 00000000 cf6a7f74 c013f1f1 f724d940 cf6a7f74 00000000 e91dc000 00000000 cf6a7fa4 00000009 00000009 e91dc005 00000000 e91dc004 Call Trace: [] [] [] [] [] [] [] Code: 0f 0b f0 fe 0d a0 46 26 c0 0f 88 ed 8b 09 00 85 c9 74 12 8b >>EIP; c0147871 <===== >> >>eax; 5a5a5a00 Before first symbol >>ebx; d907aaa0 <_end+18db8114/3854a674> >>ecx; c34d3260 <_end+32108d4/3854a674> >>edx; d907aad0 <_end+18db8144/3854a674> >>esi; c34d3260 <_end+32108d4/3854a674> >>edi; f724b620 <_end+36f88c94/3854a674> >>ebp; d907aaa0 <_end+18db8114/3854a674> >>esp; cf6a7f18 <_end+f3e558c/3854a674> Trace; c015e67e Trace; c013ea2e Trace; c013f1f1 Trace; c013f46a Trace; c013f8e1 <__user_walk+35/50> Trace; c013c51d Trace; c0106f7b Code; c0147871 00000000 <_EIP>: Code; c0147871 <===== 0: 0f 0b ud2a <===== Code; c0147873 2: f0 fe 0d a0 46 26 c0 lock decb 0xc02646a0 Code; c014787a 9: 0f 88 ed 8b 09 00 js 98bfc <_EIP+0x98bfc> c01e046d Code; c0147880 f: 85 c9 test %ecx,%ecx Code; c0147882 11: 74 12 je 25 <_EIP+0x25> c0147896 Code; c0147884 13: 8b 00 mov (%eax),%eax Details vary, of course, but the stack trace is pretty much the same always. The system is running a custom 2.4.17 kernel, the only substantial differences from the stock 686-smp kernel are CONFIG_HIGHMEM4G=y and CONFIG_MPENTIUMIII=y. I am about to upgrade to a similar 2.4.18 kernel, and will report as to whether I see this happen again (could take a few days). -- - mdz ------------------------------------------------------- -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-devfs@oss.sgi.com Sat May 4 20:18:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g453IkwJ022563 for ; Sat, 4 May 2002 20:18:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g453Ik0h022562 for devfs-outgoing; Sat, 4 May 2002 20:18:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from server.pyramid.com (userc161.torchlake.com [12.40.131.161] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g453IfwJ022559 for ; Sat, 4 May 2002 20:18:42 -0700 Received: from pyramid2.pyramid.com (pyramid2.pyramid.com [192.168.1.12]) by server.pyramid.com (8.11.1/8.11.1) with ESMTP id g453Jt029700 for ; Sat, 4 May 2002 23:19:55 -0400 Content-Type: text/plain; charset="us-ascii" From: Brian Witowski Organization: Pyramid Computer Systems To: devfs list Subject: Boot errors Date: Sat, 4 May 2002 23:19:55 +0000 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Message-Id: <200205042319.55439.brianw@torchlake.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g453IhwJ022560 Sender: owner-devfs@oss.sgi.com Precedence: bulk I am getting the following at the end of my boot: devfs_register(1): could not append to parent, err: -17 devfs_register(a1): could not append to parent, err: -17 But I get 3 occurrances of each, alternating between (a) and (a1). The are referring to /dev/vcc/1 and dev/vcc/a1, but I don't understand what the problem is. I have read that they can be ignored but I would like to clean them up if possibe. I'm running Gentoo linux, 2.4.19-r1 kernel with devfsd 1.3.24. Thanks, Brian From owner-devfs@oss.sgi.com Sun May 5 00:40:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g457eiwJ023989 for ; Sun, 5 May 2002 00:40:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g457einM023988 for devfs-outgoing; Sun, 5 May 2002 00:40:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g457ecwJ023985 for ; Sun, 5 May 2002 00:40:39 -0700 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g457fnv04776; Sun, 5 May 2002 09:41:50 +0200 (MEST) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g457fnH26010; Sun, 5 May 2002 09:41:49 +0200 (MEST) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Sun, 5 May 2002 11:47:55 +0400 Received: from [163.242.193.99] (163.242.193.99 [163.242.193.99]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KHG96X4D; Sun, 5 May 2002 11:47:51 +0400 From: Borsenkow Andrej To: Brian Witowski Cc: devfs list Subject: Re: Boot errors In-Reply-To: <200205042319.55439.brianw@torchlake.com> References: <200205042319.55439.brianw@torchlake.com> Content-Type: text/plain; charset=KOI8-R X-Mailer: Ximian Evolution 1.0.3-1mdk Date: 05 May 2002 11:41:39 +0400 Message-Id: <1020584505.3020.5.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g457eewJ023986 Sender: owner-devfs@oss.sgi.com Precedence: bulk В Вск, 05.05.2002, в 03:19, Brian Witowski написал: > I am getting the following at the end of my boot: > > devfs_register(1): could not append to parent, err: -17 > devfs_register(a1): could not append to parent, err: -17 > > But I get 3 occurrances of each, alternating between (a) and (a1). > > The are referring to /dev/vcc/1 and dev/vcc/a1, but I don't understand what > the problem is. It means 1 and a1 already exist under /dev/vcc when driver tries register them. I have read that they can be ignored but I would like to > clean them up if possibe. > The most obvious case - something restores /dev state on bootup from hardcopy using something like cp, cpio, tar or whatever. > I'm running Gentoo linux, 2.4.19-r1 kernel with devfsd 1.3.24. > With these versions there is no need to use the above. Put RESTORE in devfsd.conf, clean up whatever directory is used to save /dev state and let devfsd do its work. -andrej From owner-devfs@oss.sgi.com Tue May 7 00:06:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4776ewJ003434 for ; Tue, 7 May 2002 00:06:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4776emR003433 for devfs-outgoing; Tue, 7 May 2002 00:06:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from c007.snv.cp.net (h011.c007.snv.cp.net [209.228.33.239]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4776WwJ003427 for ; Tue, 7 May 2002 00:06:32 -0700 Received: (cpmta 18765 invoked from network); 7 May 2002 00:07:47 -0700 Received: from 65.184.234.137 (HELO dsl-65-184-234-137.telocity.com) by smtp.directvinternet.com (209.228.33.239) with SMTP; 7 May 2002 00:07:47 -0700 X-Sent: 7 May 2002 07:07:47 GMT Date: Tue, 7 May 2002 02:07:46 -0500 (CDT) From: Bill Comisky X-X-Sender: bcomisky@twain To: devfs@oss.sgi.com Subject: ide host/bus numbering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk I've just upgraded my linux system to kernel 2.4.18-6 using devfs. After playing around and looking over the documentation I could find, I still have a question about the ide device naming scheme. I have 4 ide connectors on my motherboard (Abit VP6) which are numbered 1-4 in the mobo manual (the connectors are also referred to as "channels"). They further refer to IDE1 as "primary" and IDE2 as "secondary". IDE3 and IDE4 are for ATA-100 devices. Note in the bootup messages these are ide0 - ide3. My question is, how are the "host" numbers in the ide/host* tree determined? My disk setup from dmesg is as follows (some lines removed for sake of brevity): #============================================ ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xb008-0xb00f, BIOS settings: hdc:DMA, hdd:pio ide2: BM-DMA at 0xe400-0xe407, BIOS settings: hde:DMA, hdf:DMA ide3: BM-DMA at 0xe408-0xe40f, BIOS settings: hdg:pio, hdh:pio hda: WDC WD307AA, ATA DISK drive hdc: ATAPI 44X CDROM, ATAPI CD/DVD-ROM drive hde: Maxtor 4D080H4, ATA DISK drive hdf: Maxtor 4D080H4, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 ide2 at 0xd400-0xd407,0xd802 on irq 10 hda: 60074784 sectors (30758 MB) w/2048KiB Cache, CHS=3739/255/63, UDMA(33) hde: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=158816/16/63, UDMA(100) hdf: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=9964/255/63, UDMA(100) hdc: ATAPI 40X CD-ROM drive, 128kB Cache, UDMA(33) Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 > /dev/ide/host2/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 > /dev/ide/host2/bus0/target1/lun0: p1 p2 < p5 p6 p7 p8 p9 > #============================================ ll /dev/hd? gives: /dev/hda -> ide/host0/bus0/target0/lun0/disc /dev/hdc -> ide/host0/bus1/target0/lun0/cd /dev/hde -> ide/host2/bus0/target0/lun0/disc /dev/hdf -> ide/host2/bus0/target1/lun0/disc So master/slave matches up with the target. lun is always 0. I'm just not sure how the host/bus numbers are assigned. My best guess, were I to fully populate my system with disks is (guesses in parentheses): host bus target hda 0 0 0 hdb (0) (0) (1) hdc 0 1 0 hdd (0) (1) (1) hde 2 0 0 hdf 2 0 1 hdg (2) (1) (0) hdh (2) (1) (1) So I lumped the the connectors in (primary/secondary?) pairs. Is this right? If not, what should the missing entries be? Also, where is host #1? There is no /dev/ide/host1 directory. Thanks for any answers or pointers. bill -- Bill Comisky bcomisky@pobox.com From owner-devfs@oss.sgi.com Wed May 8 23:19:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g496J0wJ023134 for ; Wed, 8 May 2002 23:19:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g496IxMe023133 for devfs-outgoing; Wed, 8 May 2002 23:18:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g496IswJ023128 for ; Wed, 8 May 2002 23:18:55 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id AF7FC92452 for ; Thu, 9 May 2002 16:20:21 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id B4DFF310F for ; Thu, 9 May 2002 16:20:23 +1000 (EST) Content-Type: text/plain; charset="us-ascii" From: Russell Coker Reply-To: Russell Coker To: devfs@oss.sgi.com Subject: /dev/discs and devfsd Date: Thu, 9 May 2002 16:20:23 +1000 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020509062023.B4DFF310F@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk When I insert a pcmcia IDE device it becomes /dev/discs/disc1 (disc0 is the internal hard drive). Then I remove it and re-insert it and it becomes /dev/discs/disc2! If the disc gets the first available number assigned to it then that would be OK. If /dev/ide/host2/bus0/target0/lun0 gets permanently assigned to be /dev/discs/disc2 (until the next reboot) then that would also be OK. But having it just get an incrementally higher number on each insertion is IMHO a bug. It's also really annoying when I have several flash-cards to read and I have to type a different mount command every time instead of "!mount". This is in devfsd 1.3.25. -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-devfs@oss.sgi.com Thu May 9 07:44:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49EiawJ028601 for ; Thu, 9 May 2002 07:44:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49EiZ2X028600 for devfs-outgoing; Thu, 9 May 2002 07:44:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49EiUwJ028597 for ; Thu, 9 May 2002 07:44:30 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g49EjhQ26251; Thu, 9 May 2002 08:45:43 -0600 Date: Thu, 9 May 2002 08:45:43 -0600 Message-Id: <200205091445.g49EjhQ26251@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: devfs@oss.sgi.com Subject: Re: /dev/discs and devfsd In-Reply-To: <20020509062023.B4DFF310F@lyta.coker.com.au> References: <20020509062023.B4DFF310F@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > When I insert a pcmcia IDE device it becomes /dev/discs/disc1 (disc0 is the > internal hard drive). > > Then I remove it and re-insert it and it becomes /dev/discs/disc2! That's not supposed to be happening! Can you verify that: - devfs_(de)alloc_unique_number() is being called upon removal/insert - the right numbers are being passed in to these calls. > If the disc gets the first available number assigned to it then that > would be OK. If /dev/ide/host2/bus0/target0/lun0 gets permanently > assigned to be /dev/discs/disc2 (until the next reboot) then that > would also be OK. > > But having it just get an incrementally higher number on each > insertion is IMHO a bug. It's also really annoying when I have > several flash-cards to read and I have to type a different mount > command every time instead of "!mount". It's broken somehow. Odd, since this has been tested. Grrrr. > This is in devfsd 1.3.25. It's not the fault of devfsd. This is handled by the kernel. Which kernel version is it? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu May 9 21:56:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4A4u8wJ001441 for ; Thu, 9 May 2002 21:56:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4A4u8Fv001440 for devfs-outgoing; Thu, 9 May 2002 21:56:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4A4u0wJ001436 for ; Thu, 9 May 2002 21:56:03 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 1403A92452; Fri, 10 May 2002 14:57:32 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id BAC17CE8; Fri, 10 May 2002 14:57:35 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Richard Gooch Subject: Re: /dev/discs and devfsd Date: Fri, 10 May 2002 14:57:35 +1000 X-Mailer: KMail [version 1.3.2] Cc: devfs@oss.sgi.com References: <20020509062023.B4DFF310F@lyta.coker.com.au> <200205091445.g49EjhQ26251@vindaloo.ras.ucalgary.ca> In-Reply-To: <200205091445.g49EjhQ26251@vindaloo.ras.ucalgary.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020510045736.BAC17CE8@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Fri, 10 May 2002 00:45, Richard Gooch wrote: > Russell Coker writes: > > When I insert a pcmcia IDE device it becomes /dev/discs/disc1 (disc0 is > > the internal hard drive). > > > > Then I remove it and re-insert it and it becomes /dev/discs/disc2! > > That's not supposed to be happening! Can you verify that: > - devfs_(de)alloc_unique_number() is being called upon removal/insert > - the right numbers are being passed in to these calls. I'll have to do that later, I don't have much spare time at the moment. > > If the disc gets the first available number assigned to it then that > > would be OK. If /dev/ide/host2/bus0/target0/lun0 gets permanently > > assigned to be /dev/discs/disc2 (until the next reboot) then that > > would also be OK. > > > > But having it just get an incrementally higher number on each > > insertion is IMHO a bug. It's also really annoying when I have > > several flash-cards to read and I have to type a different mount > > command every time instead of "!mount". > > It's broken somehow. Odd, since this has been tested. Grrrr. > > > This is in devfsd 1.3.25. > > It's not the fault of devfsd. This is handled by the kernel. Which > kernel version is it? 2.4.18. -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-devfs@oss.sgi.com Fri May 10 04:34:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ABYDwJ006881 for ; Fri, 10 May 2002 04:34:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ABYDfH006880 for devfs-outgoing; Fri, 10 May 2002 04:34:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ABY9wJ006870 for ; Fri, 10 May 2002 04:34:10 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 0605D92452 for ; Fri, 10 May 2002 21:35:42 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 1007F3283 for ; Fri, 10 May 2002 21:35:47 +1000 (EST) Content-Type: text/plain; charset="us-ascii" From: Russell Coker Reply-To: Russell Coker To: devfs@oss.sgi.com Subject: changing shared objects Date: Fri, 10 May 2002 21:35:47 +1000 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020510113548.1007F3283@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk I think that there should be a way to tell devfsd to unload shared objects from CFUNCTION/MFUNCTION entries and reload them. This would allow me to replace the shared object with a new version without requiring that devfsd be restarted. I know that the devfsd would need to be restarted if I was trying to fix a serious bug in the module (IE memory corruption), but for minor issues (changing logging messages or adding new functions) it should not be necessary to stop and restart devfsd entirely IMHO. -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-devfs@oss.sgi.com Fri May 10 08:50:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4AFoiwJ011492 for ; Fri, 10 May 2002 08:50:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4AFoiKH011491 for devfs-outgoing; Fri, 10 May 2002 08:50:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4AFodwJ011481 for ; Fri, 10 May 2002 08:50:40 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4AFpxv12075; Fri, 10 May 2002 09:51:59 -0600 Date: Fri, 10 May 2002 09:51:59 -0600 Message-Id: <200205101551.g4AFpxv12075@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: devfs@oss.sgi.com Subject: Re: changing shared objects In-Reply-To: <20020510113548.1007F3283@lyta.coker.com.au> References: <20020510113548.1007F3283@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > I think that there should be a way to tell devfsd to unload shared > objects from CFUNCTION/MFUNCTION entries and reload them. This > would allow me to replace the shared object with a new version > without requiring that devfsd be restarted. > > I know that the devfsd would need to be restarted if I was trying to > fix a serious bug in the module (IE memory corruption), but for > minor issues (changing logging messages or adding new functions) it > should not be necessary to stop and restart devfsd entirely IMHO. So you're not even happy with sending SIGHUP to devfsd? What's the harm in doing that? While I could define another signal to reload shared objects, there are a number of things I don't like about that: - code bloat - consumes yet another signal - requires struct shared_object to record the path to the library - code bloat. And besides that, it would require more code. Oh, and did I mention code bloat? Unless you can show me why this feature is so much better than just sending SIGHUP, I'm reluctant to add code to do this. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri May 10 08:56:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4AFuTwJ011569 for ; Fri, 10 May 2002 08:56:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4AFuTcx011568 for devfs-outgoing; Fri, 10 May 2002 08:56:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4AFuOwJ011565 for ; Fri, 10 May 2002 08:56:24 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4AFvpI12366; Fri, 10 May 2002 09:57:51 -0600 Date: Fri, 10 May 2002 09:57:51 -0600 Message-Id: <200205101557.g4AFvpI12366@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: Richard Gooch , devfs@oss.sgi.com Subject: Re: /dev/discs and devfsd In-Reply-To: <20020510045736.BAC17CE8@lyta.coker.com.au> References: <20020509062023.B4DFF310F@lyta.coker.com.au> <200205091445.g49EjhQ26251@vindaloo.ras.ucalgary.ca> <20020510045736.BAC17CE8@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Fri, 10 May 2002 00:45, Richard Gooch wrote: > > Russell Coker writes: > > > When I insert a pcmcia IDE device it becomes /dev/discs/disc1 (disc0 is > > > the internal hard drive). > > > > > > Then I remove it and re-insert it and it becomes /dev/discs/disc2! > > > > That's not supposed to be happening! Can you verify that: > > - devfs_(de)alloc_unique_number() is being called upon removal/insert > > - the right numbers are being passed in to these calls. > > I'll have to do that later, I don't have much spare time at the moment. > > > > If the disc gets the first available number assigned to it then that > > > would be OK. If /dev/ide/host2/bus0/target0/lun0 gets permanently > > > assigned to be /dev/discs/disc2 (until the next reboot) then that > > > would also be OK. > > > > > > But having it just get an incrementally higher number on each > > > insertion is IMHO a bug. It's also really annoying when I have > > > several flash-cards to read and I have to type a different mount > > > command every time instead of "!mount". > > > > It's broken somehow. Odd, since this has been tested. Grrrr. > > > > > This is in devfsd 1.3.25. > > > > It's not the fault of devfsd. This is handled by the kernel. Which > > kernel version is it? > > 2.4.18. Ah. There were some bugs in this code in 2.4.18. Grab 2.4.19-pre8 and let me know how it goes. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri May 10 10:30:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4AHUAwJ012379 for ; Fri, 10 May 2002 10:30:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4AHUAdi012378 for devfs-outgoing; Fri, 10 May 2002 10:30:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from ws1-9.us4.outblaze.com (205-158-62-37.outblaze.com [205.158.62.37]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4AHU7wJ012374 for ; Fri, 10 May 2002 10:30:07 -0700 Received: (qmail 73967 invoked by uid 1001); 10 May 2002 17:31:38 -0000 Message-ID: <20020510173138.73966.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [193.68.46.191] by ws1-9.us4.outblaze.com with http for marton.kadar@mail.com; Sat, 11 May 2002 01:31:38 +0800 From: "Marton Kadar" To: devfs@oss.sgi.com Date: Sat, 11 May 2002 01:31:38 +0800 Subject: 4 questions X-Originating-Ip: 193.68.46.191 X-Originating-Server: ws1-9.us4.outblaze.com Sender: owner-devfs@oss.sgi.com Precedence: bulk Hello all, I use kernel 2.4.9 with devfs support, and installed devfsd too. The fs is not mounted automatically, nor do I use the "only" option. I mount the fs manually, often not on /dev, and experiment with things before I finally dump the old /dev directory. I like the idea of devfs very much, but still have a few questions: I have read in the FAQ the following sentence: "Also, because the devfs namespace exists without any devfs mounts, you can easily mount the root filesystem by referring to an entry in the devfs namespace." 1. I find it a little confusing or at least not conceptually clear that I have to pass "root=/dev/ide/..." to the kernel even while the fs is not mounted anywhere, and that /proc/mounts will show the root device mounted on /dev/ide/... even though I might later mount the devfs to say /mnt/dev or to several mount points, all different from /dev, if I please. In fact the current setup suggests that the kernel mounts one single device node of the devfs tree but nothing else. This is kind of a chicken and egg problem: to be able to refer to the (root) device by node name (in order to mount it) you need the node, for the node to exist, however, you need the filesystem, which in turn needs the root device to be mounted. I would find it lots cleaner to be able to say "root=ide/..." or "root_device=ide/..." instead. 2. Can I persuade the kernel to mount the fs at boot time to something other than /dev? 3. Not strictly confined to devfs, but also to modutils, is this: If I compile my kernel with some devfs-aware modules, then basically the module (say sg.o) contains the information, what device node(s) it will implement (through devfs_register(), which I cannot change without kernel patching). Still I have to manually specify through a devfsd LOOKUP event and a modules.conf alias, that a request for module /dev/scsi/.../generic will really mean a request for module sg, although there is not a lot of other choices. I would appreciate comments on this apparent duplication. 4. Is devfsd the only designed way to autoload devfs-aware modules? As I understand it is the kernel-resident devfs code that detects the lookup event, and devfsd only knows about it via the .devfsd communication channel, so requesting the module would be simple without devfsd running, unless we want to carry out some special action. So much for today 8^) I'll keep trying to clear the picture, but any help would be appreciated! Marton -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup From owner-devfs@oss.sgi.com Fri May 10 10:40:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4AHeJwJ012456 for ; Fri, 10 May 2002 10:40:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4AHeJLd012455 for devfs-outgoing; Fri, 10 May 2002 10:40:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4AHeCwJ012452 for ; Fri, 10 May 2002 10:40:12 -0700 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g4AHfkT07196; Fri, 10 May 2002 19:41:46 +0200 (MEST) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g4AHfkB27046; Fri, 10 May 2002 19:41:46 +0200 (MEST) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 21:48:01 +0400 Received: from [163.242.193.99] (163.242.193.99 [163.242.193.99]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRQ62MQJ; Fri, 10 May 2002 21:47:55 +0400 From: Borsenkow Andrej To: Richard Gooch Cc: Russell Coker , devfs@oss.sgi.com Subject: Re: changing shared objects In-Reply-To: <200205101551.g4AFpxv12075@vindaloo.ras.ucalgary.ca> References: <20020510113548.1007F3283@lyta.coker.com.au> <200205101551.g4AFpxv12075@vindaloo.ras.ucalgary.ca> Content-Type: text/plain; charset=KOI8-R X-Mailer: Ximian Evolution 1.0.3-1mdk Date: 10 May 2002 21:41:34 +0400 Message-Id: <1021052500.2925.12.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4AHeDwJ012453 Sender: owner-devfs@oss.sgi.com Precedence: bulk В Птн, 10.05.2002, в 19:51, Richard Gooch написал: > Russell Coker writes: > > I think that there should be a way to tell devfsd to unload shared > > objects from CFUNCTION/MFUNCTION entries and reload them. This > > would allow me to replace the shared object with a new version > > without requiring that devfsd be restarted. > > > > I know that the devfsd would need to be restarted if I was trying to > > fix a serious bug in the module (IE memory corruption), but for > > minor issues (changing logging messages or adding new functions) it > > should not be necessary to stop and restart devfsd entirely IMHO. > > So you're not even happy with sending SIGHUP to devfsd? What's the > harm in doing that? > > While I could define another signal to reload shared objects, there > are a number of things I don't like about that: > - code bloat > - consumes yet another signal > - requires struct shared_object to record the path to the library Why? The only thing that needs to be done is to dlclose() handle and free shared_object. It will be reloaded on next access. > - code bloat. > > And besides that, it would require more code. Oh, and did I mention > code bloat? Unless you can show me why this feature is so much better > than just sending SIGHUP, I'm reluctant to add code to do this. > One example is pam_console_etc shared object. It parses /etc/security/console.perms. When this file is changed (by user or as result of RPM update) you have three alternatives: 1. Do nothing and let sysadmin manually restart devfsd 2. Check mtime on every call into shared object and reparse it 3. Reload shared object. I intended to do 2 but forgot :-) 3 is better as it avoids overhead. Of course the main problem is, shared object must be prepared to be unloaded. It must free any allocated memory it may have. I am not aware how to do it automatically - it means, it has to export some cleanup function and devfsd needs to call it ... now _that_ tends to become messy and too error prone. Really I do not think restarting devfsd is as bad. Oh, and it reminds me. When devfsd comes up (or as result of HUP) it generates synthetic REGISTER events. Unfortunately it generates it for _every_ single name it finds under /dev - including those that has never been actually registered. Mandrake even includes code that is based on this buggy assumption and works only because devfsd gets HUP during startup. Is there any chance to restrict those synthetic REGISTERs only to actually registered nodes? -andrej From owner-devfs@oss.sgi.com Fri May 10 10:52:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4AHq0wJ012572 for ; Fri, 10 May 2002 10:52:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4AHpxx1012571 for devfs-outgoing; Fri, 10 May 2002 10:51:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4AHpawJ012568 for ; Fri, 10 May 2002 10:51:37 -0700 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g4AHrAT09677 for ; Fri, 10 May 2002 19:53:10 +0200 (MEST) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g4AHrAB00760; Fri, 10 May 2002 19:53:10 +0200 (MEST) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 21:59:25 +0400 Received: from [163.242.193.99] (163.242.193.99 [163.242.193.99]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRQ62MQS; Fri, 10 May 2002 21:59:22 +0400 From: Borsenkow Andrej To: Marton Kadar Cc: devfs@oss.sgi.com Subject: Re: 4 questions In-Reply-To: <20020510173138.73966.qmail@mail.com> References: <20020510173138.73966.qmail@mail.com> Content-Type: text/plain; charset=KOI8-R X-Mailer: Ximian Evolution 1.0.3-1mdk Date: 10 May 2002 21:53:01 +0400 Message-Id: <1021053187.2924.23.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4AHpcwJ012569 Sender: owner-devfs@oss.sgi.com Precedence: bulk [every your question comes as one long like here] В Птн, 10.05.2002, в 21:31, Marton Kadar написал: > Hello all, > > I use kernel 2.4.9 with devfs support, and installed devfsd too. > The fs is not mounted automatically, nor do I use the "only" option. I mount the fs manually, often not on /dev, and experiment with things before I finally dump the old /dev directory. I like the idea of devfs very much, but still have a few questions: > > I have read in the FAQ the following sentence: > "Also, because the devfs namespace exists without any devfs mounts, you can easily mount the root filesystem by referring to an entry in the devfs namespace." > > 1. I find it a little confusing or at least not conceptually clear that I have to pass "root=/dev/ide/..." to the kernel even while the fs is not mounted anywhere, and that /proc/mounts will show the root device mounted on /dev/ide/... even though I might later mount the devfs to say /mnt/dev or to several mount points, all different from /dev, if I please. In fact the current setup suggests that the kernel mounts one single device node of the devfs tree but nothing else. This is kind of a chicken and egg problem: to be able to refer to the (root) device by node name (in order to mount it) you need the node, for the node to exist, however, you need the filesystem, which in turn needs the root device to be mounted. I would find it lots cleaner to be able to say "root=ide/..." or "root_device=ide/..." instead. > > 2. Can I persuade the kernel to mount the fs at boot time to something other than /dev? > > 3. Not strictly confined to devfs, but also to modutils, is this: If I compile my kernel with some devfs-aware modules, then basically the module (say sg.o) contains the information, what device node(s) it will implement (through devfs_register(), which I cannot change without kernel patching). Still I have to manually specify through a devfsd LOOKUP event and a modules.conf alias, that a request for module /dev/scsi/.../generic will really mean a request for module sg, although there is not a lot of other choices. I would appreciate comments on this apparent duplication. > There is no redundancy. devfs is passive. It reflects exactly the loaded drivers (actually I never liked the name. driverfs would be more close to reality). You still need to load corresponding drivers. Without devfs you have special with major so when kernel tries open unknown (a.k.a. unregistered) major number it generates modprobe for (char|block)-major-N. You do not normally see it because modutils handle most standard aliases. With devfs you do not have any file (and you do not have static major numbers as well) so you have to load drivers basing on names. In the sense it looks redundant, I agree. It could be hidden if there were standard way to export names handled by drivers; then modutils could collect them into table (just like what happens with PCI or USB) so the whole would work semi-transparent. > 4. Is devfsd the only designed way to autoload devfs-aware modules? As I understand it is the kernel-resident devfs code that detects the lookup event, and devfsd only knows about it via the .devfsd communication channel, so requesting the module would be simple without devfsd running, unless we want to carry out some special action. > You need something that receives LOOKUP event and decides what module to load. If you do not like name "devfsd" call it differently but it still has to to the same. As far as first two questions I am interested as well. -andrej From owner-devfs@oss.sgi.com Fri May 10 17:04:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4B04BwJ016922 for ; Fri, 10 May 2002 17:04:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4B04B6h016921 for devfs-outgoing; Fri, 10 May 2002 17:04:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4B045wJ016918 for ; Fri, 10 May 2002 17:04:06 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id EBBD292452; Sat, 11 May 2002 10:05:38 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id C29873733; Sat, 11 May 2002 10:03:41 +1000 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Richard Gooch Subject: Re: changing shared objects Date: Sat, 11 May 2002 10:03:41 +1000 X-Mailer: KMail [version 1.3.2] Cc: devfs@oss.sgi.com References: <20020510113548.1007F3283@lyta.coker.com.au> <200205101551.g4AFpxv12075@vindaloo.ras.ucalgary.ca> In-Reply-To: <200205101551.g4AFpxv12075@vindaloo.ras.ucalgary.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020511000341.C29873733@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Sat, 11 May 2002 01:51, Richard Gooch wrote: > > I think that there should be a way to tell devfsd to unload shared > > objects from CFUNCTION/MFUNCTION entries and reload them. This > > would allow me to replace the shared object with a new version > > without requiring that devfsd be restarted. > > > > I know that the devfsd would need to be restarted if I was trying to > > fix a serious bug in the module (IE memory corruption), but for > > minor issues (changing logging messages or adding new functions) it > > should not be necessary to stop and restart devfsd entirely IMHO. > > So you're not even happy with sending SIGHUP to devfsd? What's the > harm in doing that? > > While I could define another signal to reload shared objects, there > are a number of things I don't like about that: > - code bloat > - consumes yet another signal > - requires struct shared_object to record the path to the library > - code bloat. > > And besides that, it would require more code. Oh, and did I mention > code bloat? Unless you can show me why this feature is so much better > than just sending SIGHUP, I'm reluctant to add code to do this. SIGHUP didn't seem to do it last time I checked. I'll test again next month. -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-devfs@oss.sgi.com Fri May 10 17:08:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4B08XwJ016998 for ; Fri, 10 May 2002 17:08:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4B08XG7016997 for devfs-outgoing; Fri, 10 May 2002 17:08:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4B08SwJ016994 for ; Fri, 10 May 2002 17:08:28 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4B09rp18392; Fri, 10 May 2002 18:09:53 -0600 Date: Fri, 10 May 2002 18:09:53 -0600 Message-Id: <200205110009.g4B09rp18392@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: devfs@oss.sgi.com Subject: Re: changing shared objects In-Reply-To: <20020511000341.C29873733@lyta.coker.com.au> References: <20020510113548.1007F3283@lyta.coker.com.au> <200205101551.g4AFpxv12075@vindaloo.ras.ucalgary.ca> <20020511000341.C29873733@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Sat, 11 May 2002 01:51, Richard Gooch wrote: > > > I think that there should be a way to tell devfsd to unload shared > > > objects from CFUNCTION/MFUNCTION entries and reload them. This > > > would allow me to replace the shared object with a new version > > > without requiring that devfsd be restarted. > > > > > > I know that the devfsd would need to be restarted if I was trying to > > > fix a serious bug in the module (IE memory corruption), but for > > > minor issues (changing logging messages or adding new functions) it > > > should not be necessary to stop and restart devfsd entirely IMHO. > > > > So you're not even happy with sending SIGHUP to devfsd? What's the > > harm in doing that? > > > > While I could define another signal to reload shared objects, there > > are a number of things I don't like about that: > > - code bloat > > - consumes yet another signal > > - requires struct shared_object to record the path to the library > > - code bloat. > > > > And besides that, it would require more code. Oh, and did I mention > > code bloat? Unless you can show me why this feature is so much better > > than just sending SIGHUP, I'm reluctant to add code to do this. > > SIGHUP didn't seem to do it last time I checked. I'll test again > next month. It better. The cleanup function that is called in response to SIGHUP will unload old shared libraries. You can also use SIGUSR1 if you want to prevent synthetic REGISTER events from being generated. This is probably the one you want to use. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Fri May 10 23:07:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4B67owJ019451 for ; Fri, 10 May 2002 23:07:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4B67nlC019450 for devfs-outgoing; Fri, 10 May 2002 23:07:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4B67jwJ019447 for ; Fri, 10 May 2002 23:07:46 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4B68re24563; Sat, 11 May 2002 00:08:53 -0600 Date: Sat, 11 May 2002 00:08:53 -0600 Message-Id: <200205110608.g4B68re24563@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v212 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 212 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.5/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.5/devfs-patch-current.gz NOTE: kernel 2.5.1 and later require devfsd-v1.3.19 or later. This is against 2.5.14. Highlights of this release: - Added BKL to because drivers still need it Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun May 12 22:48:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4D5mUwJ015719 for ; Sun, 12 May 2002 22:48:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4D5mUrI015718 for devfs-outgoing; Sun, 12 May 2002 22:48:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4D5mQwJ015714 for ; Sun, 12 May 2002 22:48:26 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4D5nus15881; Sun, 12 May 2002 23:49:56 -0600 Date: Sun, 12 May 2002 23:49:56 -0600 Message-Id: <200205130549.g4D5nus15881@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v213 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 213 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.5/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.5/devfs-patch-current.gz NOTE: kernel 2.5.1 and later require devfsd-v1.3.19 or later. This is against 2.5.15. Highlights of this release: - Protected and from changing directory contents Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue May 14 10:24:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EHOknC006537 for ; Tue, 14 May 2002 10:24:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EHOkP7006536 for devfs-outgoing; Tue, 14 May 2002 10:24:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EHOenC006532 for ; Tue, 14 May 2002 10:24:41 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4EHOTY11470; Tue, 14 May 2002 11:24:29 -0600 Date: Tue, 14 May 2002 11:24:29 -0600 Message-Id: <200205141724.g4EHOTY11470@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: linux-kernel@vger.kernel.org, devfs-announce-list@vindaloo.ras.ucalgary.ca Subject: [PATCH] devfs v199.14 available Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi, all. Version 199.14 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.19-pre8. Highlights of this release: - Copied macro for error messages from fs/devfs/base.c to fs/devfs/util.c and made use of this macro - Added BKL to because drivers still need it - Protected and from changing directory contents Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Tue May 14 11:31:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EIV9nC007793 for ; Tue, 14 May 2002 11:31:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EIV9wE007792 for devfs-outgoing; Tue, 14 May 2002 11:31:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from hahasiah.localdomain (200-158-190-156.dsl.telesp.net.br [200.158.190.156]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EIV0nC007786 for ; Tue, 14 May 2002 11:31:02 -0700 Received: (from miguel@localhost) by hahasiah.localdomain (8.11.6/8.11.6) id g4EIVIe07913; Tue, 14 May 2002 15:31:18 -0300 X-Authentication-Warning: hahasiah.localdomain: miguel set sender to miguel@rozsas.xx.nom.br using -f Subject: USB serial driver isn't supported ? From: Miguel Angelo Rozsas To: devfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 May 2002 15:31:18 -0300 Message-Id: <1021401078.2358.193.camel@hahasiah> Mime-Version: 1.0 Sender: owner-devfs@oss.sgi.com Precedence: bulk Hi There ! I was using devfs since last week and looks good ! All my disks, partitions, display, mouse, keyboard, etc, all are working good. My question is about the serial driver for USB ports. Before devfs I was using /dev/usb/ttyUSB1 to syncronize my palm. The kernel was the right configuration to usb serial device. >From dmesg: usb.c: registered new driver serial usbserial.c: USB Serial support registered for Generic usbserial.c: USB Serial Driver core v1.4 usbserial.c: USB Serial support registered for Handspring Visor usbserial.c: USB Serial support registered for Palm M500 usbserial.c: USB Serial support registered for Palm M505 usbserial.c: USB Serial support registered for Sony Clie 3.5 usbserial.c: USB Serial support registered for Sony Clie 4.0 visor.c: USB HandSpring Visor, Palm m50x, Sony Clie driver v1.4 But the usb device isn't in the new /dev/usb. In fact, /dev/usb is empty. Reading TFM and SFW :-) I learned I have to create unsupported devices manually using mknod. So: cd /dev/usb mknod ttyUSB0 c 188 0 mknod ttyUSB1 c 188 1 chown miguel ttyUSB* (miguel is the local user who wants to sync the palm) But coldsync doesn't work anymore. I missed something ? [miguel@hahasiah ~]% coldsync -mb .palm/backup Warning: no device on /dev/usb/ttyUSB1. Sleeping Warning: no device on /dev/usb/ttyUSB1. Sleeping Warning: no device on /dev/usb/ttyUSB1. Sleeping Warning: no device on /dev/usb/ttyUSB1. Sleeping Warning: no device on /dev/usb/ttyUSB1. Sleeping I am using kernel 2.4.18 on a RH 7.2, coldsync 2.2.5. This setup already worked on a old-style /dev. The only thing was changed is devfs. Any hints ? Any suggestions will be appreciated. best regards from Brazil, From owner-devfs@oss.sgi.com Wed May 15 15:46:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FMkGnC003603 for ; Wed, 15 May 2002 15:46:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FMkGoe003602 for devfs-outgoing; Wed, 15 May 2002 15:46:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FMkCnC003598 for ; Wed, 15 May 2002 15:46:13 -0700 Received: from slc-unislc.slc.unisys.com ([192.60.174.32]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id WAA24148 for ; Wed, 15 May 2002 22:45:02 GMT Received: from localhost.localdomain (slc-knysna.slc.unisys.com [192.60.130.30]) by slc-unislc.slc.unisys.com (8.9.3/UW7.1.1) with ESMTP id QAA01268 for ; Wed, 15 May 2002 16:46:30 -0600 (MDT) Received: from slc-knysna (slc-knysna [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g4FMkZX26624 for ; Wed, 15 May 2002 16:46:35 -0600 Content-Type: text/plain; charset="us-ascii" From: Warren Stockton Reply-To: wns@slc.unisys.com To: devfs@oss.sgi.com Subject: devfs and raw devices Date: Wed, 15 May 2002 16:46:34 -0600 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200205151646.35083.wns@slc.unisys.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk I have been searching for more info on devfs and raw devices and would appreciate a few pointers. Running devfsd 1.3.25 on 2.4.9 and 2.4.18 kernels does not create /dev/rawctl or associated /dev/raw devices, but raw devices work fine if the device nodes are manually created. Additionally, drivers/char/raw.c does not implement any defvs_*() calls for creating/deleting the device nodes. Is there any plan to support raw devices with devfs? -- Warren Stockton mailto: wns@slc.unisys.com From owner-devfs@oss.sgi.com Wed May 15 21:59:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G4xwnC013273 for ; Wed, 15 May 2002 21:59:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G4xwIV013272 for devfs-outgoing; Wed, 15 May 2002 21:59:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G4xrnC013269 for ; Wed, 15 May 2002 21:59:54 -0700 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g4G50Jn12339; Thu, 16 May 2002 07:00:19 +0200 (MEST) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g4G50Ji08626; Thu, 16 May 2002 07:00:19 +0200 (MEST) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 09:06:44 +0400 Received: from MW1G17C ([163.242.193.31]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K08Q30FP; Thu, 16 May 2002 09:06:41 +0400 From: Borsenkow Andrej To: wns@slc.unisys.com, devfs@oss.sgi.com Subject: RE: devfs and raw devices Date: Thu, 16 May 2002 09:00:13 +0400 Message-ID: <6134254DE87BD411908B00A0C99B044F02E89AB0@mowd019a.mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200205151646.35083.wns@slc.unisys.com> Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk > > I have been searching for more info on devfs and raw devices and would > appreciate a few pointers. > > Running devfsd 1.3.25 on 2.4.9 and 2.4.18 kernels does not create > /dev/rawctl > or associated /dev/raw devices, but raw devices work fine if the device > nodes > are manually created. > > Additionally, drivers/char/raw.c does not implement any defvs_*() calls for > creating/deleting the device nodes. > > Is there any plan to support raw devices with devfs? > several patches has been posted to lkml; one of them is integrated in current Mandrake kernel (8.2 and above). Try to contact raw maintainer/Marcelo/Alan asking for including this patch in mainstream. -andrej From owner-devfs@oss.sgi.com Sat May 18 08:20:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4IFK2nC028374 for ; Sat, 18 May 2002 08:20:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4IFK2tN028373 for devfs-outgoing; Sat, 18 May 2002 08:20:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4IFJsnC028354 for ; Sat, 18 May 2002 08:19:55 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 0206492460; Sun, 19 May 2002 01:20:08 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 632EC4198; Sun, 19 May 2002 01:17:25 +1000 (EST) From: Russell Coker Reply-To: Russell Coker To: Eduard Bloch , 146768-maintonly@bugs.debian.org Subject: Re: Bug#146768: devfsd: does not create /dev/ttyUSB* Date: Sun, 19 May 2002 00:34:31 +1000 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: Cc: devfs@oss.sgi.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_JT9B15FQAE6YCF77EO0B" Message-Id: <20020518151725.632EC4198@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk --------------Boundary-00=_JT9B15FQAE6YCF77EO0B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit On Mon, 13 May 2002 07:11, you wrote: > Package: devfsd > Version: 1.3.25-6 > Severity: minor > > See subject. devfsd should create this symlinks for backwards > compatibility with locations described in the kernel documentation... > > usbserial.c: Handspring Visor converter now attached to ttyUSB0 (or > usb/tts/0 for devfs) usbserial.c: Handspring Visor converter now attached > to ttyUSB1 (or usb/tts/1 for devfs) The attached patch will be in the next Debian package to address this issue. Richard, please consider it for the next upstream release. Russell Coker --------------Boundary-00=_JT9B15FQAE6YCF77EO0B Content-Type: text/x-diff; charset="iso-8859-1"; name="diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="diff" LS0tIC90bXAvY29tcGF0X25hbWUuYwlTdW4gTWF5IDE5IDAwOjMxOjAzIDIwMDIKKysrIGNvbXBh dF9uYW1lLmMJU3VuIE1heSAxOSAwMDozMjozMyAyMDAyCkBAIC0xMjMsNiArMTIzLDcgQEAKICAg ICB7ImN1YS9GIiwgICAgICAiY3VmJXMifSwgICAgICAgIC8qICBDb21wdXRvbmUgc2VyaWFsIGRy aXZlciBjYWxsb3V0ICAgICAgKi8KICAgICB7InR0cy9DIiwgICAgICAidHR5QyVzIn0sICAgICAg IC8qICBDeWNsYWRlcyBzZXJpYWwgZHJpdmVyICAgICAgICAgICAgICAgKi8KICAgICB7ImN1YS9D IiwgICAgICAiY3ViJXMifSwgICAgICAgIC8qICBDeWNsYWRlcyBzZXJpYWwgZHJpdmVyIGNhbGxv dXQgICAgICAgKi8KKyAgICB7InVzYi90dHMvIiwgICAidHR5VVNCJXMifSwgICAgIC8qICBVU0Ig c2VyaWFsIGRyaXZlciAgICAgICAgICAgICAgICAgICAgKi8KICAgICB7InR0cy8iLCAgICAgICAi dHR5UyVzIn0sICAgICAgIC8qICBHZW5lcmljIHNlcmlhbDogbXVzdCBiZSBhZnRlciBvdGhlcnMg Ki8KICAgICB7ImN1YS8iLCAgICAgICAiY3VhJXMifSwgICAgICAgIC8qICBHZW5lcmljIHNlcmlh bDogbXVzdCBiZSBhZnRlciBvdGhlcnMgKi8KICAgICB7ImlucHV0L2pzIiwgICAianMlcyJ9LCAg ICAgICAgIC8qICBKb3lzdGljayBkcml2ZXIgICAgICAgICAgICAgICAgICAgICAgKi8K --------------Boundary-00=_JT9B15FQAE6YCF77EO0B-- From owner-devfs@oss.sgi.com Sun May 19 11:07:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JI7SnC021921 for ; Sun, 19 May 2002 11:07:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JI7Sak021920 for devfs-outgoing; Sun, 19 May 2002 11:07:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4JI7NnC021902 for ; Sun, 19 May 2002 11:07:23 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4JI7t618335; Sun, 19 May 2002 12:07:55 -0600 Date: Sun, 19 May 2002 12:07:55 -0600 Message-Id: <200205191807.g4JI7t618335@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: Eduard Bloch , devfs@oss.sgi.com Subject: Re: Bug#146768: devfsd: does not create /dev/ttyUSB* In-Reply-To: <20020518151725.632EC4198@lyta.coker.com.au> References: <20020518151725.632EC4198@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Mon, 13 May 2002 07:11, you wrote: > > Package: devfsd > > Version: 1.3.25-6 > > Severity: minor > > > > See subject. devfsd should create this symlinks for backwards > > compatibility with locations described in the kernel documentation... > > > > usbserial.c: Handspring Visor converter now attached to ttyUSB0 (or > > usb/tts/0 for devfs) usbserial.c: Handspring Visor converter now attached > > to ttyUSB1 (or usb/tts/1 for devfs) > > The attached patch will be in the next Debian package to address this issue. > > Richard, please consider it for the next upstream release. Applied. Thanks. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Sun May 19 15:04:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JM4InC012496 for ; Sun, 19 May 2002 15:04:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JM4Ih6012495 for devfs-outgoing; Sun, 19 May 2002 15:04:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from surf.viawest.net (surf.viawest.net [216.87.64.26]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4JM48nC012452 for ; Sun, 19 May 2002 15:04:08 -0700 Received: from bellicha.wizard.com (dyn75.nas7.vegas.viawest.net [209.170.209.75]) by surf.viawest.net (8.12.3/8.12.3/viawest-1.0) with ESMTP id g4JM4plE011138 for ; Sun, 19 May 2002 16:04:52 -0600 (MDT) Received: (from bradl@localhost) by bellicha.wizard.com (8.11.6/8.11.6) id g4JM4pB06024 for devfs@oss.sgi.com; Sun, 19 May 2002 15:04:51 -0700 Date: Sun, 19 May 2002 15:04:50 -0700 From: A Guy Called Tyketto To: devfs@oss.sgi.com Subject: /dev/cdrom and devfs v213 Message-ID: <20020519220450.GA6014@wizard.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Operating-System: Linux/2.5.16 (i686) X-uptime: 3:03pm up 13:43, 2 users, load average: 0.00, 0.00, 0.00 X-RSA-KeyID: 0xE9DF4D85 X-DSA-KeyID: 0xE319F0BF X-GPG-Keys: see http://www.wizard.com/~tyketto/pgp.html Sender: owner-devfs@oss.sgi.com Precedence: bulk I'll make it short. Has anyone had a problem with a non-root user trying to access /dev/cdrom? I have an IDE cd-rw in my linux box (2.5.16), w/devfs enabled at boot. 2.5.16 compiled cleanly, and booted successfully. However, when running a simple cd audio program, like workbone or xplaycd, neither are able to access /dev/cdrom as a non-root user. my setup: bradl@bellicha:~> ls -l /dev/cdrom lr-xr-xr-x 1 root root 13 May 19 01:21 /dev/cdrom -> cdroms/cdrom0 bradl@bellicha:~> ls -l /dev/cdroms/cdrom0 lr-xr-xr-x 1 root root 33 Dec 31 1969 /dev/cdroms/cdrom0 -> ../ide/host1/bus1/target0/lun0/cd bradl@bellicha:~> ls -l /dev/ide/host1/bus1/target0/lun0/cd brw-rw-rw- 1 root root 22, 0 Dec 31 1969 /dev/ide/host1/bus1/target0/lun0/cd strace on workbone returns: open("/dev/cdrom", O_RDONLY) = 3 "..., 55 ioctl(3, CDROMSUBCHNL, 0xbfffe654) = -1 EACCES (Permission denied) rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(0, SNDCTL_TMR_START, {B38400 opost isig -icanon -echo ...}) = 0 ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0 write(1, "\n", 1 ) = 1 ioctl(0, SNDCTL_TMR_START, {B38400 opost isig icanon echo ...}) = 0 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigaction(SIGINT, {SIG_DFL}, {SIG_IGN}, 8) = 0 munmap(0x40017000, 4096) = 0 _exit(0) = ? strace on xplaycd returns: read(5, "/dev/ide/host0/bus0/target0/lun0"..., 4096) = 1003 read(5, "", 4096) = 0 close(5) = 0 munmap(0x4001a000, 4096) = 0 open("/dev/cdrom", O_RDONLY) = 5 ioctl(5, CDROMSUBCHNL, 0xbfffe584) = -1 EACCES (Permission denied) close(5) = 0 ioctl(4, SOUND_MIXER_READ_CD, 0xbffff5b0) = 0 open("/etc/mtab", O_RDONLY) = 5 fstat64(0x5, 0xbfffddec) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 read(5, "/dev/ide/host0/bus0/target0/lun0"..., 4096) = 1003 read(5, "", 4096) = 0 close(5) = 0 munmap(0x4001a000, 4096) = 0 open("/dev/cdrom", O_RDONLY) = 5 ioctl(5, CDROMSUBCHNL, 0xbfffe484) = -1 EACCES (Permission denied) close(5) = 0 my current devfsd.conf has: # # Uncomment this if you want the old /dev/cdrom symlink # (e.g. those specifying CD-ROM type, mouse port, modem port etc) # #LOOKUP ^cdrom$ CFUNCTION GLOBAL symlink cdroms/cdrom0 $devpath #REGISTER ^cdrom/cdrom0$ CFUNCTION GLOBAL symlink cdroms/cdrom0 cdrom #UNREGISTER ^cdrom/cdrom0$ CFUNCTION GLOBAL unlink cdrom REGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL mksymlink $devname cdrom UNREGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL unlink cdrom Anything I'm missing here? This worked in 2.5.7, which, IIRC, used devfs v211. BL. From owner-devfs@oss.sgi.com Sun May 19 15:58:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JMwNnC023006 for ; Sun, 19 May 2002 15:58:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JMwNRk023005 for devfs-outgoing; Sun, 19 May 2002 15:58:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from sabi.co.UK ([217.158.107.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4JMwBnC022957 for ; Sun, 19 May 2002 15:58:16 -0700 Received: from localhost ([127.0.0.1] helo=home.sabi.co.UK) by sabi.co.UK with esmtp (Exim 3.16 #1) id 179Zdd-0006bq-00 for devfs@OSS.SGI.com; Sun, 19 May 2002 23:58:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15592.11821.536753.56145@home.sabi.co.UK> Date: Sun, 19 May 2002 23:58:53 +0100 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: Re: /dev/cdrom and devfs v213 In-Reply-To: <20020519220450.GA6014@wizard.com> References: <20020519220450.GA6014@wizard.com> X-Mailer: VM 6.95 under 21.4 (patch 4) "Artificial Intelligence" 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 Sender: owner-devfs@oss.sgi.com Precedence: bulk >>> On Sun, 19 May 2002 15:04:50 -0700, A Guy Called Tyketto >>> said: tyketto> I'll make it short. Has anyone had a problem with a tyketto> non-root user trying to access /dev/cdrom? [ ... ] The first line in my '/etc/devsfd.conf' is 'INCLUDE /etc/devfsd.local', and then I have a file '/etc/devfs.local' in which I put local configuration, including permissions, such as: ------------------------------------------------------------------------ REGISTER ^ide/host0/bus1/target0/lun0/cd$ COPY $devpath cdrom UNREGISTER ^ide/host0/bus1/target0/lun0/cd$ EXECUTE rm cdrom REGISTER ^scsi/host0/bus0/target3/lun0/generic$ COPY $devpath cdr UNREGISTER ^scsi/host0/bus0/target3/lun0/generic$ EXECUTE rm cdr REGISTER ^cdrom[0-9]*$ PERMISSIONS root.disk 0444 REGISTER ^cdr[0-9]*$ PERMISSIONS root.root 0660 ------------------------------------------------------------------------ From owner-devfs@oss.sgi.com Sun May 19 16:57:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JNvlnC003682 for ; Sun, 19 May 2002 16:57:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JNvl5T003680 for devfs-outgoing; Sun, 19 May 2002 16:57:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from surf.viawest.net (surf.viawest.net [216.87.64.26]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4JNvdnC003639 for ; Sun, 19 May 2002 16:57:39 -0700 Received: from bellicha.wizard.com (dyn138.nas8.vegas.viawest.net [209.170.209.138]) by surf.viawest.net (8.12.3/8.12.3/viawest-1.0) with ESMTP id g4JNwMlE020111; Sun, 19 May 2002 17:58:23 -0600 (MDT) Received: (from bradl@localhost) by bellicha.wizard.com (8.11.6/8.11.6) id g4JNwMY00336; Sun, 19 May 2002 16:58:22 -0700 Date: Sun, 19 May 2002 16:58:22 -0700 From: A Guy Called Tyketto To: Piercarlo Grandi Cc: devfs@oss.sgi.com Subject: Re: /dev/cdrom and devfs v213 Message-ID: <20020519235822.GA298@wizard.com> References: <20020519220450.GA6014@wizard.com> <15592.11821.536753.56145@home.sabi.co.UK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15592.11821.536753.56145@home.sabi.co.UK> User-Agent: Mutt/1.3.28i X-Operating-System: Linux/2.5.16 (i686) X-uptime: 4:48pm up 4 min, 3 users, load average: 0.08, 0.11, 0.05 X-RSA-KeyID: 0xE9DF4D85 X-DSA-KeyID: 0xE319F0BF X-GPG-Keys: see http://www.wizard.com/~tyketto/pgp.html Sender: owner-devfs@oss.sgi.com Precedence: bulk On Sun, May 19, 2002 at 11:58:53PM +0100, Piercarlo Grandi wrote: > >>> On Sun, 19 May 2002 15:04:50 -0700, A Guy Called Tyketto > >>> said: > > tyketto> I'll make it short. Has anyone had a problem with a > tyketto> non-root user trying to access /dev/cdrom? [ ... ] > > The first line in my '/etc/devsfd.conf' is 'INCLUDE /etc/devfsd.local', > and then I have a file '/etc/devfs.local' in which I put local > configuration, including permissions, such as: > > ------------------------------------------------------------------------ > REGISTER ^ide/host0/bus1/target0/lun0/cd$ COPY $devpath cdrom > UNREGISTER ^ide/host0/bus1/target0/lun0/cd$ EXECUTE rm cdrom > REGISTER ^scsi/host0/bus0/target3/lun0/generic$ COPY $devpath cdr > UNREGISTER ^scsi/host0/bus0/target3/lun0/generic$ EXECUTE rm cdr > > REGISTER ^cdrom[0-9]*$ PERMISSIONS root.disk 0444 > REGISTER ^cdr[0-9]*$ PERMISSIONS root.root 0660 > ------------------------------------------------------------------------ Aye, but the location of the entry and permissions in either file really have nothing to do with why the device is not usable by a non-root user, when given permissions 0666, or even 0660: #REGISTER ^ide/host0/bus1/target0/lun0/cd$ CFUNCTION GLOBAL mksymlink $devname cdrom REGISTER ^ide/host0/bus1/target0/lun0/cd$ COPY $devpath cdrom REGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL mksymlink $devname cdrom UNREGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL unlink cdrom REGISTER ^cdrom[0-9]*$ PERMISSIONS root.root 0644 REGISTER ^cdrom[0-9]*$ PERMISSIONS root.root 0644 root@bellicha:/dev/ide/host1/bus1/target0/lun0# ls -al total 0 drwxr-xr-x 1 root root 0 Dec 31 1969 ./ drwxr-xr-x 1 root root 0 Dec 31 1969 ../ brw-rw-rw- 1 root root 22, 0 Dec 31 1969 cd root@bellicha:/dev/ide/host1/bus1/target0/lun0# open("/dev/cdrom", O_RDONLY) = 3 ioctl(3, CDROMSUBCHNL, 0xbfffe814) = -1 EACCES (Permission denied) rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(0, SNDCTL_TMR_START, {B38400 opost isig -icanon -echo ...}) = 0 ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0 write(1, "\n", 1 ) = 1 ioctl(0, SNDCTL_TMR_START, {B38400 opost isig icanon echo ...}) = 0 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigaction(SIGINT, {SIG_DFL}, {SIG_IGN}, 8) = 0 munmap(0x40017000, 4096) = 0 _exit(0) = ? > ^D Script done on Sun May 19 16:56:39 2002 BL. From owner-devfs@oss.sgi.com Mon May 20 00:34:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K7Y1nC032204 for ; Mon, 20 May 2002 00:34:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K7Y1YY032203 for devfs-outgoing; Mon, 20 May 2002 00:34:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K7XvnC032187 for ; Mon, 20 May 2002 00:33:58 -0700 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g4K7Yh808681; Mon, 20 May 2002 09:34:43 +0200 (MEST) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g4K7YfS05548; Mon, 20 May 2002 09:34:42 +0200 (MEST) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 11:41:14 +0400 Received: from ITSRM2 ([163.242.193.17]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LGDYR2SW; Mon, 20 May 2002 11:41:12 +0400 From: Borsenkow Andrej To: A Guy Called Tyketto Cc: Piercarlo Grandi , devfs@oss.sgi.com Date: Mon, 20 May 2002 11:34:37 +0400 (MSD) X-X-Sender: bor@itsrm2.mow.siemens.ru Subject: Re: /dev/cdrom and devfs v213 In-Reply-To: <20020519235822.GA298@wizard.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk On Sun, 19 May 2002, A Guy Called Tyketto wrote: > > Aye, but the location of the entry and permissions in either file > really have nothing to do with why the device is not usable by a non-root > user, when given permissions 0666, or even 0660: > It is usable. As your strace shows, user can read CD just fine. It is one particular IOCTL that fails. May be 2.5 put some restrictions on who can use this ioctl? -andrej From owner-devfs@oss.sgi.com Mon May 20 01:19:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K8JQnC005467 for ; Mon, 20 May 2002 01:19:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K8JQnC005466 for devfs-outgoing; Mon, 20 May 2002 01:19:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from emory.viawest.net (emory.viawest.net [216.87.64.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K8JKnC005444 for ; Mon, 20 May 2002 01:19:20 -0700 Received: from bellicha.wizard.com (dyn10.nas6.vegas.viawest.net [209.170.209.10]) by emory.viawest.net (8.12.3/8.12.3/viawest-2.1) with ESMTP id g4K8Jjtg010904; Mon, 20 May 2002 02:19:46 -0600 (MDT) Received: (from bradl@localhost) by bellicha.wizard.com (8.11.6/8.11.6) id g4K8Jiu01719; Mon, 20 May 2002 01:19:44 -0700 Date: Mon, 20 May 2002 01:19:44 -0700 From: A Guy Called Tyketto To: Borsenkow Andrej Cc: devfs@oss.sgi.com Subject: Re: /dev/cdrom and devfs v213 Message-ID: <20020520081944.GA1700@wizard.com> References: <20020519235822.GA298@wizard.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Operating-System: Linux/2.5.7 (i686) X-uptime: 1:16am up 34 min, 2 users, load average: 0.10, 0.03, 0.01 X-RSA-KeyID: 0xE9DF4D85 X-DSA-KeyID: 0xE319F0BF X-GPG-Keys: see http://www.wizard.com/~tyketto/pgp.html Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, May 20, 2002 at 11:34:37AM +0400, Borsenkow Andrej wrote: > On Sun, 19 May 2002, A Guy Called Tyketto wrote: > > > > > Aye, but the location of the entry and permissions in either file > > really have nothing to do with why the device is not usable by a non-root > > user, when given permissions 0666, or even 0660: > > > > It is usable. As your strace shows, user can read CD just fine. It is one > particular IOCTL that fails. > > May be 2.5 put some restrictions on who can use this ioctl? > > -andrej Hmm.. You may be right. I fell back to 2.5.7, did an strace on workbone, and got: open("/dev/cdrom", O_RDONLY) = 3 "..., 55 ioctl(3, CDROMSUBCHNL, 0xbfffe654) = 0 ioctl(3, CDROMREADTOCHDR, 0xbfffe626) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 ioctl(3, CDROMREADTOCENTRY, 0xbfffe628) = 0 rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(0, SNDCTL_TMR_START, {B38400 opost isig -icanon -echo ...}) = 0 ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0 Which is normal, as it's waiting for user input on the number pad. in 2.5.16, it throws you back out to your prompt, with the trace previously posted. I'll throw this over to the LKML, along with another unrelated issue I have with 2.5. BL. From owner-devfs@oss.sgi.com Mon May 20 11:37:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KIbhnC008359 for ; Mon, 20 May 2002 11:37:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KIbh4Q008358 for devfs-outgoing; Mon, 20 May 2002 11:37:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from umbriel.eastgw.xerox.com (umbriel.xerox.com [208.140.33.26]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KIbcnC008346 for ; Mon, 20 May 2002 11:37:39 -0700 Received: from "Firewall" (mswitch2.cinops.xerox.com [13.250.20.172]) by umbriel.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA11056 for ; Mon, 20 May 2002 14:38:14 -0400 (EDT) Received: from CONVERSION-DAEMON.mgate.usa.xerox.com by mgate.usa.xerox.com (PMDF V6.1 #39864) id <0GWF009019YTF7@mgate.usa.xerox.com> for devfs@oss.sgi.com; Mon, 20 May 2002 14:28:05 -0400 (EDT) Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mgate.usa.xerox.com (PMDF V6.1 #39864) with ESMTP id <0GWF008IM9YT1T@mgate.usa.xerox.com> for devfs@oss.sgi.com; Mon, 20 May 2002 14:28:05 -0400 (EDT) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 14:38:26 -0400 Content-return: allowed Date: Mon, 20 May 2002 14:38:22 -0400 From: "Luo, Ling" Subject: Another /dev/cdrom question To: devfs@oss.sgi.com Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Sender: owner-devfs@oss.sgi.com Precedence: bulk I found that the /dev/cdroms and symbolic link /dev/cdrom do not appear under /dev until I cd into /dev/discs or /dev/ide. Is there a way to make the two entries appear under /dev automatically after reboot? Here are some information 2.4.18 kernel + devfs 213 linuxplat-9:/dev/ide/cd <253> ll total 0 lr-xr-xr-x 1 root root 29 May 20 14:21 c0b0t1u0 -> ../host0/bus0/target1/lun0/cd devfsd.conf : # # Uncomment this if you want the old /dev/cdrom symlink REGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL mksymlink $devname cdrom UNREGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL unlink cdrom From owner-devfs@oss.sgi.com Mon May 20 12:20:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KJKAnC015884 for ; Mon, 20 May 2002 12:20:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KJKAYf015883 for devfs-outgoing; Mon, 20 May 2002 12:20:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from hahasiah.localdomain (200-158-190-146.dsl.telesp.net.br [200.158.190.146]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KJK3nC015847 for ; Mon, 20 May 2002 12:20:04 -0700 Received: (from miguel@localhost) by hahasiah.localdomain (8.11.6/8.11.6) id g4KJKkV02327; Mon, 20 May 2002 16:20:46 -0300 X-Authentication-Warning: hahasiah.localdomain: miguel set sender to miguel@rozsas.xx.nom.br using -f Subject: Re: Another /dev/cdrom question From: Miguel Angelo Rozsas To: devfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 May 2002 16:20:46 -0300 Message-Id: <1021922446.2135.24.camel@hahasiah> Mime-Version: 1.0 Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, 2002-05-20 at 15:38, Luo, Ling wrote: > I found that the /dev/cdroms and symbolic link /dev/cdrom do not appear > under /dev until I cd into /dev/discs or /dev/ide. > Is there a way to make the two entries appear under /dev automatically after > reboot? > I am having a similar problem with ZIP disks not inserted on zip drive at boot time. The problem is /dev/hdc and /dev/hdc4 aren't available even after I insert a disk on drive. . I have uncommented the following lines on /etc/devfs.conf and got an error when devfsd starts. IDE NEWCOMPAT /dev/ide/hd/* names LOOKUP ^(ide/hd/c[0-9]+b[0-9]+t[0-9]+u[0-9]+)p[0-9]+$ EXECUTE /bin/dd if=$mntpnt/\1 of=/dev/null count=1 IDE OLDCOMPAT /dev/hd?? names LOOKUP ^(hd[a-z])[0-9]+$ EXECUTE /bin/dd if=$mntpnt/\1 of=/dev/null count=1 Error message at boot time: Bad WHEN in config line: "IDE NEWCOMPAT /dev/ide/hd/* names" My system is a RH 7.2 kernel 2.4.18, devfsd 1.3.25, internal IDE ZIP 250. If there is a disk at boot time, the device drive exists on /dev/ide/host0/bus1/target0/lun0/{disc,part4} and /dev/hdc[4] Any hints ? regards, From owner-devfs@oss.sgi.com Mon May 20 12:36:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KJaGnC018492 for ; Mon, 20 May 2002 12:36:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KJaGqr018491 for devfs-outgoing; Mon, 20 May 2002 12:36:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from mail.labsysgrp.com (wsip68-14-236-254.ph.ph.cox.net [68.14.236.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KJa9nC018457 for ; Mon, 20 May 2002 12:36:09 -0700 Received: from mail by mail.labsysgrp.com with scanned-ok (Exim 3.34 #1) id 179sxh-0001KL-00 for devfs@oss.sgi.com; Mon, 20 May 2002 12:36:53 -0700 Received: from jeeves.kpf.internal ([192.168.170.1]) by mail.labsysgrp.com with esmtp (Exim 3.34 #1) id 179sxg-0001K2-00; Mon, 20 May 2002 12:36:52 -0700 Received: from [192.168.172.108] (helo=kpfhome) by jeeves.kpf.internal with smtp (Exim 3.35 #1) id 179sxg-0001by-00; Mon, 20 May 2002 12:36:52 -0700 Message-ID: <019f01c20035$b0623cd0$6caca8c0@kpfhome> From: "Kevin P. Fleming" To: "Miguel Angelo Rozsas" , References: <1021922446.2135.24.camel@hahasiah> Subject: Re: Another /dev/cdrom question Date: Mon, 20 May 2002 12:36:51 -0700 Organization: Laboratory Systems Group, 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS snapshot-20010714 Sender: owner-devfs@oss.sgi.com Precedence: bulk There are patches at http://members.cox.net/kpfleming/ide-floppy to work around this problem. ----- Original Message ----- From: "Miguel Angelo Rozsas" To: Sent: Monday, May 20, 2002 12:20 PM Subject: Re: Another /dev/cdrom question > On Mon, 2002-05-20 at 15:38, Luo, Ling wrote: > > I found that the /dev/cdroms and symbolic link /dev/cdrom do not appear > > under /dev until I cd into /dev/discs or /dev/ide. > > Is there a way to make the two entries appear under /dev automatically after > > reboot? > > > > I am having a similar problem with ZIP disks not inserted on zip drive > at boot time. The problem is /dev/hdc and /dev/hdc4 aren't available > even after I insert a disk on drive. > . > I have uncommented the following lines on /etc/devfs.conf and got an > error when devfsd starts. > > > IDE NEWCOMPAT /dev/ide/hd/* names > LOOKUP ^(ide/hd/c[0-9]+b[0-9]+t[0-9]+u[0-9]+)p[0-9]+$ EXECUTE /bin/dd > if=$mntpnt/\1 of=/dev/null count=1 > IDE OLDCOMPAT /dev/hd?? names > LOOKUP ^(hd[a-z])[0-9]+$ EXECUTE /bin/dd if=$mntpnt/\1 of=/dev/null > count=1 > > Error message at boot time: > > Bad WHEN in config line: "IDE NEWCOMPAT /dev/ide/hd/* names" > > My system is a RH 7.2 kernel 2.4.18, devfsd 1.3.25, internal IDE ZIP > 250. > > If there is a disk at boot time, the device drive exists on > > /dev/ide/host0/bus1/target0/lun0/{disc,part4} and /dev/hdc[4] > > > Any hints ? > > regards, > > > > > > > From owner-devfs@oss.sgi.com Mon May 20 16:56:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KNuJnC030544 for ; Mon, 20 May 2002 16:56:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KNuI54030543 for devfs-outgoing; Mon, 20 May 2002 16:56:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from linuxbrothers (mail@124-165-58-66-cable.juneau.ak.net [66.58.165.124] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KNuGnC030540 for ; Mon, 20 May 2002 16:56:17 -0700 Received: from 67-167-58-66.gci.net ([66.58.167.67] helo=linuxbrothers.homeip.net ident=azreal) by linuxbrothers with esmtp (Exim 3.35 #1 (Debian)) id 179xHT-0001Q5-00 for ; Mon, 20 May 2002 16:13:35 -0800 Message-ID: <3CE98D51.70909@linuxbrothers.homeip.net> Date: Mon, 20 May 2002 15:57:05 -0800 From: Azreal Arcane User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: devfs@oss.sgi.com Subject: /dev/dvd Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-devfs@oss.sgi.com Precedence: bulk hi, stupid question i can probably imagine, but i need the link /dev/dvd on the /dev fs, how can i go about doing that correctly? thanx From owner-devfs@oss.sgi.com Mon May 20 23:01:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L616nC026702 for ; Mon, 20 May 2002 23:01:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L616qu026701 for devfs-outgoing; Mon, 20 May 2002 23:01:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L60wnC026695 for ; Mon, 20 May 2002 23:00:59 -0700 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g4L61nk16840; Tue, 21 May 2002 08:01:49 +0200 (MEST) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g4L61mq01236; Tue, 21 May 2002 08:01:48 +0200 (MEST) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 10:08:23 +0400 Received: from ITSRM2 ([163.242.193.17]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LK2GJSBK; Tue, 21 May 2002 10:08:18 +0400 From: Borsenkow Andrej To: "Luo, Ling" Cc: devfs@oss.sgi.com Date: Tue, 21 May 2002 10:01:41 +0400 (MSD) X-X-Sender: bor@itsrm2.mow.siemens.ru Subject: Re: Another /dev/cdrom question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, 20 May 2002, Luo, Ling wrote: > I found that the /dev/cdroms and symbolic link /dev/cdrom do not appear > under /dev until I cd into /dev/discs or /dev/ide. > Is there a way to make the two entries appear under /dev automatically after > reboot? > Compile ide-cd in kernel, not as module. Entries appear as soon as driver is loaded and driver is loaded when you try to access any entry for the first time. -andrej From owner-devfs@oss.sgi.com Tue May 21 11:19:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4LIJtnC004684 for ; Tue, 21 May 2002 11:19:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4LIJsrU004683 for devfs-outgoing; Tue, 21 May 2002 11:19:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from chubaka.homeip.net (i232048.ppp.asahi-net.or.jp [61.125.232.48]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4LIJnnC004680 for ; Tue, 21 May 2002 11:19:50 -0700 Received: (qmail 25817 invoked by uid 500); 21 May 2002 18:28:28 -0000 Date: Wed, 22 May 2002 03:28:28 +0900 From: Georgi Georgiev Cc: devfs@oss.sgi.com Subject: Re: /dev/dvd Message-ID: <20020521182828.GA25735@thunder.my.home> Reply-To: chutz@chubaka.homeip.net References: <3CE98D51.70909@linuxbrothers.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CE98D51.70909@linuxbrothers.homeip.net> User-Agent: Mutt/1.3.99-current-20020514i Sender: owner-devfs@oss.sgi.com Precedence: bulk On Mon, May 20, 2002 at 03:57:05PM -0800, Azreal Arcane wrote: > hi, > stupid question i can probably imagine, but i need the link /dev/dvd on > the /dev fs, > how can i go about doing that correctly? [chutz@thunder chutz]$ cat /etc/devfsd.conf | grep dvd REGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL mksymlink $devname dvd UNREGISTER ^cdroms/cdrom0$ CFUNCTION GLOBAL unlink dvd -- Georgi Georgiev ------------------------------------------ I still live. -Daniel Webster, dying words (contributed by Chris Johnston) From owner-devfs@oss.sgi.com Thu May 23 10:18:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NHItnC026068 for ; Thu, 23 May 2002 10:18:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NHItHX026067 for devfs-outgoing; Thu, 23 May 2002 10:18:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4NHIknC026064 for ; Thu, 23 May 2002 10:18:47 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4NHJmF04619; Thu, 23 May 2002 11:19:48 -0600 Date: Thu, 23 May 2002 11:19:48 -0600 Message-Id: <200205231719.g4NHJmF04619@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: devfs@oss.sgi.com Cc: Miguel Angelo Rozsas Subject: Re: USB serial driver isn't supported ? Sender: owner-devfs@oss.sgi.com Precedence: bulk [Repost because the previous version with devfsd appended was bounced by the list] Miguel Angelo Rozsas writes: > Hi There ! > > I was using devfs since last week and looks good ! > All my disks, partitions, display, mouse, keyboard, etc, all are working > good. > > My question is about the serial driver for USB ports. > > Before devfs I was using /dev/usb/ttyUSB1 to syncronize my palm. > The kernel was the right configuration to usb serial device. > >From dmesg: > usb.c: registered new driver serial > usbserial.c: USB Serial support registered for Generic > usbserial.c: USB Serial Driver core v1.4 > usbserial.c: USB Serial support registered for Handspring Visor > usbserial.c: USB Serial support registered for Palm M500 > usbserial.c: USB Serial support registered for Palm M505 > usbserial.c: USB Serial support registered for Sony Clie 3.5 > usbserial.c: USB Serial support registered for Sony Clie 4.0 > visor.c: USB HandSpring Visor, Palm m50x, Sony Clie driver v1.4 > > But the usb device isn't in the new /dev/usb. In fact, /dev/usb is > empty. > > Reading TFM and SFW :-) I learned I have to create unsupported devices > manually using mknod. So: > > cd /dev/usb > mknod ttyUSB0 c 188 0 > mknod ttyUSB1 c 188 1 > chown miguel ttyUSB* (miguel is the local user who wants to sync the > palm) > > But coldsync doesn't work anymore. I missed something ? > > [miguel@hahasiah ~]% coldsync -mb .palm/backup > Warning: no device on /dev/usb/ttyUSB1. Sleeping > Warning: no device on /dev/usb/ttyUSB1. Sleeping > Warning: no device on /dev/usb/ttyUSB1. Sleeping > Warning: no device on /dev/usb/ttyUSB1. Sleeping > Warning: no device on /dev/usb/ttyUSB1. Sleeping I don't know if you've already had an answer to this, but please try the appended version of devfsd. It will create compatibility entries for /dev/ttyUSB*. One thing confuses me: you seem to be creating/using /dev/usb/ttyUSB* devices, not /dev/ttyUSB* devices. I was under the impression that the official names for USB serial devices was /dev/ttyUSB* and not /dev/usb/ttyUSB*. Russell: is the patch you sent me for USB serial compat names bogus? Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu May 23 10:39:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NHdtnC026228 for ; Thu, 23 May 2002 10:39:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NHdt5b026227 for devfs-outgoing; Thu, 23 May 2002 10:39:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4NHdmnC026222 for ; Thu, 23 May 2002 10:39:50 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4NHeUB04843; Thu, 23 May 2002 11:40:30 -0600 Date: Thu, 23 May 2002 11:40:30 -0600 Message-Id: <200205231740.g4NHeUB04843@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: "Marton Kadar" Cc: devfs@oss.sgi.com Subject: Re: 4 questions In-Reply-To: <20020510173138.73966.qmail@mail.com> References: <20020510173138.73966.qmail@mail.com> Sender: owner-devfs@oss.sgi.com Precedence: bulk Marton Kadar writes: > Hello all, > > I use kernel 2.4.9 with devfs support, and installed devfsd too. > The fs is not mounted automatically, nor do I use the "only" option. I mount the fs manually, often not on /dev, and experiment with things before I finally dump the old /dev directory. I like the idea of devfs very much, but still have a few questions: Please fix your mailer to wrap lines at 70 characters. Your email is hard to read. > I have read in the FAQ the following sentence: > "Also, because the devfs namespace exists without any devfs mounts, you can easily mount the root filesystem by referring to an entry in the devfs namespace." > > 1. I find it a little confusing or at least not conceptually clear that I have to pass "root=/dev/ide/..." to the kernel even while the fs is not mounted anywhere, and that /proc/mounts will show the root device mounted on /dev/ide/... even though I might later mount the devfs to say /mnt/dev or to several mount points, all different from /dev, if I please. In fact the current setup suggests that the kernel mounts one single device node of the devfs tree but nothing else. This is kind of a chicken and egg problem: to be able to refer to the (root) device by node name (in order to mount it) you need the node, for the node to exist, however, you need the filesystem, which in turn needs the root device to be mounted. I would find it lots cleaner to be able to say "root=ide/..." or "root_device=ide/..." instead. That may even work. Have you tried it? > 2. Can I persuade the kernel to mount the fs at boot time to > something other than /dev? No. This may change in 2.5 when the initial rootfs work is complete. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu May 23 10:41:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NHffnC026271 for ; Thu, 23 May 2002 10:41:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NHffFh026270 for devfs-outgoing; Thu, 23 May 2002 10:41:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4NHfSnC026267 for ; Thu, 23 May 2002 10:41:29 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4NHWwD04771; Thu, 23 May 2002 11:32:58 -0600 Date: Thu, 23 May 2002 11:32:58 -0600 Message-Id: <200205231732.g4NHWwD04771@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Borsenkow Andrej Cc: Russell Coker , devfs@oss.sgi.com Subject: Re: changing shared objects In-Reply-To: <1021052500.2925.12.camel@localhost.localdomain> References: <20020510113548.1007F3283@lyta.coker.com.au> <200205101551.g4AFpxv12075@vindaloo.ras.ucalgary.ca> <1021052500.2925.12.camel@localhost.localdomain> Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej writes: > В Птн, 10.05.2002, в 19:51, Richard Gooch написал: Please fix your mailer to format the above line in English. > > Russell Coker writes: > > > I think that there should be a way to tell devfsd to unload shared > > > objects from CFUNCTION/MFUNCTION entries and reload them. This > > > would allow me to replace the shared object with a new version > > > without requiring that devfsd be restarted. > > > > > > I know that the devfsd would need to be restarted if I was trying to > > > fix a serious bug in the module (IE memory corruption), but for > > > minor issues (changing logging messages or adding new functions) it > > > should not be necessary to stop and restart devfsd entirely IMHO. > > > > So you're not even happy with sending SIGHUP to devfsd? What's the > > harm in doing that? > > > > While I could define another signal to reload shared objects, there > > are a number of things I don't like about that: > > - code bloat > > - consumes yet another signal > > - requires struct shared_object to record the path to the library > > Why? The only thing that needs to be done is to dlclose() handle and > free shared_object. It will be reloaded on next access. No, dlopen(3) is called from get_shared_object(), which in turn is called from process_config_line(). It's not done during event processing. Thus, the name of the object to load is not recorded anywhere. That saves space in the config_entry_struct, RTFS :-) > > - code bloat. > > > > And besides that, it would require more code. Oh, and did I mention > > code bloat? Unless you can show me why this feature is so much better > > than just sending SIGHUP, I'm reluctant to add code to do this. > > > > One example is pam_console_etc shared object. It parses > /etc/security/console.perms. When this file is changed (by user or as > result of RPM update) you have three alternatives: > > 1. Do nothing and let sysadmin manually restart devfsd Fine. > 2. Check mtime on every call into shared object and reparse it Fine too. Not my problem. It's actually cheap to do. > 3. Reload shared object. Send SIGUSR to devfsd. > I intended to do 2 but forgot :-) 3 is better as it avoids overhead. Yep. Send SIGUSR1 to devfsd. > Of course the main problem is, shared object must be prepared to be > unloaded. It must free any allocated memory it may have. I am not aware > how to do it automatically - it means, it has to export some cleanup > function and devfsd needs to call it ... now _that_ tends to become > messy and too error prone. Why do you think it's messy? I have no problem with defining a cleanup symbol that is called for shared objects that want to maintain state. If the cleanup symbol isn't there, it doesn't get called. Easy. > Really I do not think restarting devfsd is as bad. Your choice. > Oh, and it reminds me. When devfsd comes up (or as result of HUP) it > generates synthetic REGISTER events. Unfortunately it generates it for > _every_ single name it finds under /dev - including those that has never > been actually registered. Mandrake even includes code that is based on > this buggy assumption and works only because devfsd gets HUP during > startup. > > Is there any chance to restrict those synthetic REGISTERs only to > actually registered nodes? No, because there really isn't a good way of distinguishing between stuff created by drivers and stuff created from user-space when scanning. That information is only available when processing events coming from devfs. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Thu May 23 10:51:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NHpwnC026400 for ; Thu, 23 May 2002 10:51:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NHpwDq026399 for devfs-outgoing; Thu, 23 May 2002 10:51:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4NHprnC026396 for ; Thu, 23 May 2002 10:51:54 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id D99CC92452; Fri, 24 May 2002 03:52:53 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 1EBB41D5B; Thu, 23 May 2002 19:52:44 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Richard Gooch , devfs@oss.sgi.com Subject: Re: USB serial driver isn't supported ? Date: Thu, 23 May 2002 19:52:43 +0200 X-Mailer: KMail [version 1.3.2] Cc: Miguel Angelo Rozsas References: <200205231719.g4NHJmF04619@vindaloo.ras.ucalgary.ca> In-Reply-To: <200205231719.g4NHJmF04619@vindaloo.ras.ucalgary.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020523175244.1EBB41D5B@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Thu, 23 May 2002 19:19, Richard Gooch wrote: > I don't know if you've already had an answer to this, but please try > the appended version of devfsd. It will create compatibility entries > for /dev/ttyUSB*. One thing confuses me: you seem to be creating/using > /dev/usb/ttyUSB* devices, not /dev/ttyUSB* devices. > > I was under the impression that the official names for USB serial > devices was /dev/ttyUSB* and not /dev/usb/ttyUSB*. > > Russell: is the patch you sent me for USB serial compat names bogus? To the best of my knowledge it's good (I wouldn't have sent it to you otherwise), and the person who requested it seems happy. My patch complies with kernel documentation, practise among different distributions may vary though... -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-devfs@oss.sgi.com Thu May 23 15:20:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NMKlnC009801 for ; Thu, 23 May 2002 15:20:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NMKlBt009800 for devfs-outgoing; Thu, 23 May 2002 15:20:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from chubaka.homeip.net (i232048.ppp.asahi-net.or.jp [61.125.232.48]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4NMKZnC009796 for ; Thu, 23 May 2002 15:20:36 -0700 Received: (qmail 11808 invoked by uid 500); 23 May 2002 22:29:44 -0000 Date: Fri, 24 May 2002 07:29:44 +0900 From: Georgi Georgiev To: devfs@oss.sgi.com Subject: unplugging USB mouse under X does not unlink input/mouse0 Message-ID: <20020523222944.GA11535@thunder.my.home> Reply-To: chutz@chubaka.homeip.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.99-current-20020514i Sender: owner-devfs@oss.sgi.com Precedence: bulk As suggested (or at least according to my understing) I am forwarding this mail here, just in case someone has similar problem or a solution at hand. Maybe I should mail the USB guys as well? ----- Forwarded message from Richard Gooch ----- From: Richard Gooch Subject: Re: devfs: unplugging USB mouse under X does not unlink input/mouse0 To: chutz@chubaka.homeip.net Date: Thu, 23 May 2002 11:01:31 -0600 Georgi Georgiev writes: > I am not sure this is a real bug, and I did find a workaround for > now, but I decided to anyway let you know (you said to first try to > mail YOU if we have a bug to report about devfs). Actually, emailing the devfs@oss.sgi.com mailing list is preferred. That will get to me, but will also let others interested in devfs issues to see it. BTW: please fix your mailer to wrap lines at 70 characters. Your email is hard to read. > Here is the problem. > > I have set my mouse device in XFree86 to be /dev/input/mouse0. > If I unplug my USB mouse while X is running the /dev/input/mouse0 file is not > unlinked (I believe the reason is in the X server still using the mousedev > module, because I cannot rmmod it either, but that is just my opinion). What > happens if I plug the mouse in again is that a /dev/input/mouse1 device is > created and the mouse is no more usable under X because obviously X is > reading mouse0. What are the major and minor numbers of all entries in /dev/input ? > As a workaround for now I set my mouse device to be /dev/input/mice and that > does the trick. > > Maybe this workaround could find its place in the FAQ. I like unplugging my > mouse so that the screensaver is activated without problems when I am away > from the computer. > > I think the problem could be easily reproduced. > > I did not have this problem without devfs, so I guess I am mailing > the right person ;) Well, I didn't write the devfs support for USB, and it sounds like this is a bug in USB. So probably the best people to talk to first in this case are the USB developers. I don't use USB myself, so I'm not in a position that I can test it, either. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca ----- End forwarded message ----- I am also including the answer to Richard's question about major and minor numbers: [chutz@thunder chutz]$ ll /dev/input/ total 0 crw-r--r-- 1 root root 13, 63 Jan 1 1970 mice crw-r--r-- 1 root root 13, 32 Jan 1 1970 mouse0 My X right now is set to use /dev/input/mice for input. I tried unplugging and replugging - it works fine. However, I did a "cat /dev/input/mouse0" in another console and then tried the unplug - plug trick again. Here is the same command again: [chutz@thunder chutz]$ ll /dev/input/ total 0 crw-r--r-- 1 root root 13, 63 Jan 1 1970 mice crw-r--r-- 1 root root 13, 32 Jan 1 1970 mouse0 crw-r--r-- 1 root root 13, 33 Jan 1 1970 mouse1 I guess we can forget the part with X. Keeping the device busy with a cat does the trick as well. It is more than obvious that the device file is not removed if it is still being used, but I guess this really is a USB problem. -- Georgi Georgiev ------------------------------------------ Gravity is an unforgiving motherfucker. From owner-devfs@oss.sgi.com Fri May 24 04:52:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4OBqlnC031794 for ; Fri, 24 May 2002 04:52:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4OBqlgm031793 for devfs-outgoing; Fri, 24 May 2002 04:52:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from hahasiah.localdomain (200-158-190-25.dsl.telesp.net.br [200.158.190.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4OBqenC031778 for ; Fri, 24 May 2002 04:52:41 -0700 Received: (from miguel@localhost) by hahasiah.localdomain (8.11.6/8.11.6) id g4OBrLh11365; Fri, 24 May 2002 08:53:21 -0300 X-Authentication-Warning: hahasiah.localdomain: miguel set sender to miguel@rozsas.xx.nom.br using -f Subject: Re: USB serial driver isn't supported ? From: Miguel Angelo Rozsas To: Russell Coker Cc: devfs@oss.sgi.com In-Reply-To: <20020523175244.1EBB41D5B@lyta.coker.com.au> References: <200205231719.g4NHJmF04619@vindaloo.ras.ucalgary.ca> <20020523175244.1EBB41D5B@lyta.coker.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 24 May 2002 08:53:21 -0300 Message-Id: <1022241201.2214.12.camel@hahasiah> Mime-Version: 1.0 Sender: owner-devfs@oss.sgi.com Precedence: bulk On Thu, 2002-05-23 at 14:52, Russell Coker wrote: > On Thu, 23 May 2002 19:19, Richard Gooch wrote: > > I don't know if you've already had an answer to this, but please try > > the appended version of devfsd. It will create compatibility entries > > for /dev/ttyUSB*. One thing confuses me: you seem to be creating/using > > /dev/usb/ttyUSB* devices, not /dev/ttyUSB* devices. > > > > I was under the impression that the official names for USB serial > > devices was /dev/ttyUSB* and not /dev/usb/ttyUSB*. > > > > Russell: is the patch you sent me for USB serial compat names bogus? > > To the best of my knowledge it's good (I wouldn't have sent it to you > otherwise), and the person who requested it seems happy. My patch complies > with kernel documentation, practise among different distributions may vary > though... > Hi ! Using /dev/usb/ttyUSB was a misunderstanding of mine. The correct path for serial usb is /dev/usb/tts/[01] or /dev/ttyUSB[01] for compatibility. I create MANUALLY /dev/usb/ttyUSB[01] using mknod for test purposes. Now, everything is ok. I am using /dev/usb/tts/1 and is working just fine for sync my palm. Just a complimentary information, the original problem is with coldsync handling usb connections and passwords set at palm, not with the serial usb driver itself. The fellows coldsync's developers already have a path for coldsync. regards, From owner-devfs@oss.sgi.com Fri May 24 06:30:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ODUhnC004769 for ; Fri, 24 May 2002 06:30:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ODUhII004768 for devfs-outgoing; Fri, 24 May 2002 06:30:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from hahasiah.localdomain (200-158-190-25.dsl.telesp.net.br [200.158.190.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ODUbnC004765 for ; Fri, 24 May 2002 06:30:38 -0700 Received: (from miguel@localhost) by hahasiah.localdomain (8.11.6/8.11.6) id g4ODV2A13854; Fri, 24 May 2002 10:31:02 -0300 X-Authentication-Warning: hahasiah.localdomain: miguel set sender to miguel@rozsas.xx.nom.br using -f Subject: Re: Another /dev/cdrom question From: Miguel Angelo Rozsas To: "Kevin P. Fleming" Cc: devfs@oss.sgi.com In-Reply-To: <019f01c20035$b0623cd0$6caca8c0@kpfhome> References: <1021922446.2135.24.camel@hahasiah> <019f01c20035$b0623cd0$6caca8c0@kpfhome> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 24 May 2002 10:31:02 -0300 Message-Id: <1022247062.2213.101.camel@hahasiah> Mime-Version: 1.0 Sender: owner-devfs@oss.sgi.com Precedence: bulk Thanks for the hint. It worked for me. I e-mailed Paul Bristow just to his knowledge and to say thank you for his work. On Mon, 2002-05-20 at 16:36, Kevin P. Fleming wrote: > There are patches at http://members.cox.net/kpfleming/ide-floppy to work > around this problem. > > > > On Mon, 2002-05-20 at 15:38, Luo, Ling wrote: > > > I found that the /dev/cdroms and symbolic link /dev/cdrom do not appear > > > under /dev until I cd into /dev/discs or /dev/ide. > > > Is there a way to make the two entries appear under /dev automatically > after > > > reboot? > > > > > > > I am having a similar problem with ZIP disks not inserted on zip drive > > at boot time. The problem is /dev/hdc and /dev/hdc4 aren't available > > even after I insert a disk on drive. > > . From owner-devfs@oss.sgi.com Mon May 27 12:38:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4RJcGnC015548 for ; Mon, 27 May 2002 12:38:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4RJcGph015547 for devfs-outgoing; Mon, 27 May 2002 12:38:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from nova.botz.org (adsl-63-207-97-74.dsl.snfc21.pacbell.net [63.207.97.74]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4RJcCnC015543 for ; Mon, 27 May 2002 12:38:12 -0700 Received: from nova.botz.org (jbotz@localhost) by nova.botz.org (8.11.6/8.11.6) with ESMTP id g4RJdLQ14812 for ; Mon, 27 May 2002 12:39:21 -0700 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: devfs@oss.sgi.com Subject: devfs and raw devices again Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 May 2002 12:39:21 -0700 Message-ID: <14811.1022528361@nova.botz.org> From: jurgen@botz.org Sender: owner-devfs@oss.sgi.com Precedence: bulk I took a look at a couple of the patches that are floating around to make raw devices work with devfs, and I found them all a bit unsatisfying. The problem is that they pre-generate a fixed number of raw device files in devfs which don't actually do anything until they are bound. It seems to me that it would be much more devfs-ish to just create the control device initially and then generate raw device files as needed. This is possible, but would require some minor changes to the 'raw' utility. Here's how I think it should work... initially we just have... /dev/raw/ctl To bind a raw device for i.e. /dev/scsi/.../part2 you just do... $ raw /dev/scsi/.../part2 /dev/raw/1 ..the raw utility prints the name of the raw device it has bound, which now appears in devfs. In addition devfs now has symlinks... /dev/scsi/.../rpart2 -> /dev/raw/1 /dev/discs/disc0/rpart2 -> /dev/raw/1 ..etc. Comments? :j From owner-devfs@oss.sgi.com Mon May 27 15:09:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4RM9jnC017397 for ; Mon, 27 May 2002 15:09:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4RM9jDa017396 for devfs-outgoing; Mon, 27 May 2002 15:09:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4RM9bnC017393 for ; Mon, 27 May 2002 15:09:38 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4RMAkJ22002; Mon, 27 May 2002 16:10:46 -0600 Date: Mon, 27 May 2002 16:10:46 -0600 Message-Id: <200205272210.g4RMAkJ22002@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: jurgen@botz.org Cc: devfs@oss.sgi.com Subject: Re: devfs and raw devices again In-Reply-To: <14811.1022528361@nova.botz.org> References: <14811.1022528361@nova.botz.org> Sender: owner-devfs@oss.sgi.com Precedence: bulk jurgen@botz.org writes: > I took a look at a couple of the patches that are floating around > to make raw devices work with devfs, and I found them all a bit > unsatisfying. The problem is that they pre-generate a fixed > number of raw device files in devfs which don't actually do anything > until they are bound. It seems to me that it would be much more > devfs-ish to just create the control device initially and then > generate raw device files as needed. This is possible, but would > require some minor changes to the 'raw' utility. > > Here's how I think it should work... initially we just have... > > /dev/raw/ctl > > To bind a raw device for i.e. /dev/scsi/.../part2 you just do... > > $ raw /dev/scsi/.../part2 > /dev/raw/1 > > ..the raw utility prints the name of the raw device it has bound, > which now appears in devfs. In addition devfs now has symlinks... > > /dev/scsi/.../rpart2 -> /dev/raw/1 > /dev/discs/disc0/rpart2 -> /dev/raw/1 > > ..etc. Comments? Sounds reasonable. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca From owner-devfs@oss.sgi.com Mon May 27 22:14:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4S5EsnC005241 for ; Mon, 27 May 2002 22:14:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4S5Er8u005240 for devfs-outgoing; Mon, 27 May 2002 22:14:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4S5EinC005237 for ; Mon, 27 May 2002 22:14:45 -0700 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g4S5FpE06891; Tue, 28 May 2002 07:15:52 +0200 (MEST) Received: from MOWD019A.mow.siemens.ru ([139.24.18.3]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g4S5FpY05250; Tue, 28 May 2002 07:15:51 +0200 (MEST) Received: by mowd019a.mow.siemens.ru with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 09:22:37 +0400 Received: from MW1G17C ([163.242.193.31]) by MOWD019A.mow.siemens.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYV396Z0; Tue, 28 May 2002 09:22:36 +0400 From: Borsenkow Andrej To: "'Richard Gooch'" , jurgen@botz.org Cc: devfs@oss.sgi.com Subject: RE: devfs and raw devices again Date: Tue, 28 May 2002 09:15:48 +0400 Message-ID: <6134254DE87BD411908B00A0C99B044F02E89B05@mowd019a.mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200205272210.g4RMAkJ22002@vindaloo.ras.ucalgary.ca> Importance: Normal Sender: owner-devfs@oss.sgi.com Precedence: bulk > > I took a look at a couple of the patches that are floating around > > to make raw devices work with devfs, and I found them all a bit > > unsatisfying. The problem is that they pre-generate a fixed > > number of raw device files in devfs which don't actually do anything > > until they are bound. It seems to me that it would be much more > > devfs-ish to just create the control device initially and then > > generate raw device files as needed. This is possible, but would > > require some minor changes to the 'raw' utility. > > > > Here's how I think it should work... initially we just have... > > > > /dev/raw/ctl > > > > To bind a raw device for i.e. /dev/scsi/.../part2 you just do... > > > > $ raw /dev/scsi/.../part2 > > /dev/raw/1 > > > > ..the raw utility prints the name of the raw device it has bound, > > which now appears in devfs. In addition devfs now has symlinks... > > > > /dev/scsi/.../rpart2 -> /dev/raw/1 > > /dev/discs/disc0/rpart2 -> /dev/raw/1 > > > > ..etc. Comments? > > Sounds reasonable. > I do not think so. Most applications for raw devices need fixed predictable names. Oracle admin hardly will be pleased with the fact that his tablespaces change name on every reboot. Ability to add (or possibly free) raw devices online is useful though. -andrej From owner-devfs@oss.sgi.com Mon May 27 22:38:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4S5cpnC005847 for ; Mon, 27 May 2002 22:38:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4S5cpfp005846 for devfs-outgoing; Mon, 27 May 2002 22:38:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from nova.botz.org (adsl-63-207-97-74.dsl.snfc21.pacbell.net [63.207.97.74]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4S5cknC005816 for ; Mon, 27 May 2002 22:38:46 -0700 Received: from nova.botz.org (jbotz@localhost) by nova.botz.org (8.11.6/8.11.6) with ESMTP id g4S5arm27605; Mon, 27 May 2002 22:36:53 -0700 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Borsenkow Andrej Cc: devfs@oss.sgi.com Subject: Re: devfs and raw devices again In-Reply-To: Your message of "Tue, 28 May 2002 09:15:48 +0400." <6134254DE87BD411908B00A0C99B044F02E89B05@mowd019a.mow.siemens.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 May 2002 22:36:53 -0700 Message-ID: <27604.1022564213@nova.botz.org> From: jurgen@botz.org Sender: owner-devfs@oss.sgi.com Precedence: bulk Borsenkow Andrej wrote: > I do not think so. Most applications for raw devices need fixed > predictable names. Oracle admin hardly will be pleased with the fact > that his tablespaces change name on every reboot. The namespace issues are a bit separate from what I was talking about, but the device names would remain predictable in any case. If you used this mechanism very naively you could shoot yourself in the foot of course, but you can do that now. The ultimate goal is to make the names much more predictable by having them appear as things like /dev/scsi/busN/.../rdisc, etc., but I haven't got that far yet. :j From owner-devfs@oss.sgi.com Tue May 28 06:21:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SDLvnC020434 for ; Tue, 28 May 2002 06:21:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SDLvGr020433 for devfs-outgoing; Tue, 28 May 2002 06:21:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SDLpnC020429 for ; Tue, 28 May 2002 06:21:52 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 4AA0992461; Tue, 28 May 2002 23:23:12 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id 7023241D0; Tue, 28 May 2002 15:23:01 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: jurgen@botz.org, Borsenkow Andrej Subject: Re: devfs and raw devices again Date: Tue, 28 May 2002 09:18:37 +0200 X-Mailer: KMail [version 1.3.2] Cc: devfs@oss.sgi.com References: <27604.1022564213@nova.botz.org> In-Reply-To: <27604.1022564213@nova.botz.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020528132301.7023241D0@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Tue, 28 May 2002 07:36, jurgen@botz.org wrote: > Borsenkow Andrej wrote: > > I do not think so. Most applications for raw devices need fixed > > predictable names. Oracle admin hardly will be pleased with the fact > > that his tablespaces change name on every reboot. > > The namespace issues are a bit separate from what I was talking about, > but the device names would remain predictable in any case. If you > used this mechanism very naively you could shoot yourself in the foot > of course, but you can do that now. > > The ultimate goal is to make the names much more predictable by having > them appear as things like /dev/scsi/busN/.../rdisc, etc., but I > haven't got that far yet. What exactly is wrong with /dev/scsi/busN/.../rdisc and /dev/scsi/busN/.../rpart1? Why not have raw disk device nodes managed the same way as regular disk device nodes. Surely a problem in one type implies a problem in the other? -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-devfs@oss.sgi.com Tue May 28 06:26:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SDQInC020661 for ; Tue, 28 May 2002 06:26:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SDQI5X020660 for devfs-outgoing; Tue, 28 May 2002 06:26:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SDQCnC020657 for ; Tue, 28 May 2002 06:26:13 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 239EB92460; Tue, 28 May 2002 23:27:34 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id B02AC41C7; Tue, 28 May 2002 15:27:23 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Stephen Smalley Subject: Re: devfs mysterious relabelling Date: Tue, 28 May 2002 15:27:23 +0200 X-Mailer: KMail [version 1.3.2] Cc: SE Linux , devfs@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020528132723.B02AC41C7@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk On Tue, 28 May 2002 15:04, Stephen Smalley wrote: > On Fri, 24 May 2002, Russell Coker wrote: > > On my systems I have devfsd do most of the device node labelling. > > > > I have noticed that often the system_u:object_r:fixed_disk_device_t > > labels (for /dev/ide/host0/bus0/target0/lun0/*) will get changed to > > system_u:object_r:devfs_t (the default context for devfs). > > > > It doesn't happen to the device node for the entire file system > > /dev/ide/host0/bus0/target0/lun0/disc and the device node > > /dev/ide/host0/bus0/target0/lun0/part5 (an extended partition). > > > > I believe that this is not a user-land issue, and it's something in the > > kernel (but I have not proven this yet). > > > > Also it seems to happen more often when under load (setfiles on the root > > file system usually does the job). > > This could happen if a devfs entry is evicted from the dcache and is later > looked up again, causing the security context to be re-acquired from the > devfs_contexts configuration. Doesn't this issue also arise for the > ownership and mode on devfs entries when they are managed by devfsd? No! Devfs preserves the results of chmod/chown operations until the next reboot. I'm surprised though, I thought that devfs entries would be locked in the dcache... -- If you send email to me or to a mailing list that I use which has >4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. From owner-devfs@oss.sgi.com Tue May 28 07:03:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SE3gnC021854 for ; Tue, 28 May 2002 07:03:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SE3gN1021853 for devfs-outgoing; Tue, 28 May 2002 07:03:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-devfs@oss.sgi.com using -f Received: from vindaloo.ras.ucalgary.ca (vindaloo.ras.ucalgary.ca [136.159.55.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SE3anC021849 for ; Tue, 28 May 2002 07:03:36 -0700 Received: (from rgooch@localhost) by vindaloo.ras.ucalgary.ca (8.10.0/8.10.0) id g4SE4ju17785; Tue, 28 May 2002 08:04:45 -0600 Date: Tue, 28 May 2002 08:04:45 -0600 Message-Id: <200205281404.g4SE4ju17785@vindaloo.ras.ucalgary.ca> From: Richard Gooch To: Russell Coker Cc: Stephen Smalley , devfs@oss.sgi.com Subject: Re: devfs mysterious relabelling In-Reply-To: <20020528132723.B02AC41C7@lyta.coker.com.au> References: <20020528132723.B02AC41C7@lyta.coker.com.au> Sender: owner-devfs@oss.sgi.com Precedence: bulk Russell Coker writes: > On Tue, 28 May 2002 15:04, Stephen Smalley wrote: > > On Fri, 24 May 2002, Russell Coker wrote: > > > On my systems I have devfsd do most of the device node labelling. > > > > > > I have noticed that often the system_u:object_r:fixed_disk_device_t > > > labels (for /dev/ide/host0/bus0/target0/lun0/*) will get changed to > > > system_u:object_r:devfs_t (the default context for devfs). > > > > > > It doesn't happen to the device node for the entire file system > > > /dev/ide/host0/bus0/target0/lun0/disc and the device node > > > /dev/ide/host0/bus0/target0/lun0/part5 (an extended partition). > > > > > > I believe that this is not a user-land issue, and it's something in the > > > kernel (but I have not proven this yet). > > > > > > Also it seems to happen more often when under load (setfiles on the root > > > file system usually does the job). > > > > This could happen if a devfs entry is evicted from the dcache and is later > > looked up again, causing the security context to be re-acquired from the > > devfs_contexts configuration. Doesn't this issue also arise for the > > ownership and mode on devfs entries when they are managed by devfsd? > > No! Devfs preserves the results of chmod/chown operations until the > next reboot. Or until the entry is unregistered (and if you haven't configured devfsd to restore permissions). > I'm surprised though, I thought that devfs entries would be locked > in the dcache... Nope. Devfs currently uses it's own backing store (i.e. file tree), thus devfs dentries may be freed. That's going to change in 2.5, however. Note: I'm not subscribed to the (closed) SE Linux list so I've removed it from the Cc: line. Regards, Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca