Re: devfs not making vn devices
In message [EMAIL PROTECTED], Doug Barton writes: I've been using devfs for a long time without problems. I had device vn in my kernel conf since the pre-devfs days, and today I needed to use a vn device to build picobsd. Lo and behold, I don't have any vn devices of any sort in /dev. I tried 'vnconfig -c /dev/vn0' but it also complained that the device didn't exist. Use md instead of vn, it has all the same (and more) functionality. See mdconfig(8). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message 18334.980748975@critter Poul-Henning Kamp writes: : 1. Say I want to use DEVFS, what should I change? : : Nothing. Just add DEVFS to your kernel config file. So it updates /dev all by itself? What if I want dev nodes elsewhere in the tree, say for a jail? mount -t devfs devfs /home/jail/dev would work, but all dynamic devices would appear there too. Once we have an extensible facility for mount options, you will be able to say: mount -t devfs devfs /home/jail/dev ( cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ) mount -u -o nonewdev /home/jail/dev To solve that problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: pcm driver and DEVFS
Hello, Thank you for advices. Now I obtain same environment as of pre-devfs days. From: Alex Kapranoff [EMAIL PROTECTED] Date: Fri, 2 Feb 2001 15:29:09 +0300 Yep. I have these in my /etc/rc.devfs: = ln -fs /dev/audio1.0 /dev/audio ln -fs /dev/dsp1.0 /dev/dsp ln -fs /dev/mixer1 /dev/mixer = This produces almost exactly same environment both with DEVFS and without. I tried this solusion. Everything around sound drivers works. But, the another solution From: John Baldwin [EMAIL PROTECTED] Date: Fri, 02 Feb 2001 11:33:34 -0800 (PST) Add 'hw.snd.unit=1' to /boot/loader.conf. also works fine. The links suggested by the above also created automatically. In order to examin this, I commented out the lines looks like: ln -fs /dev/audio1.0 /dev/audio ln -fs /dev/dsp1.0 /dev/dsp ln -fs /dev/mixer1 /dev/mixer and reboot the system, I found actually /dev/dsp, /dev/audio and so on. Finally, please let me point out that there are no description about hw.snd.unit MIB in sysctl(8) manpage yet. Thanks!! koya To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for non-netgraph bridge code worthy of attention forpeople experimenting with bridging setups (including ng_bridge)
"Rogier R. Mulhuijzen" wrote: I found this while experimenting with both "legacy" bridge and ng_bridge. The bridging code doesn't check its activation everywhere so when I started using an ng_bridge node I started getting weird errors. Patch is rather simple, can someone submit this? I'm a litle confused when I look at this patch. I think this is the wrong fix. I see that you are accounting for packets coming in on two interfaces, but the aim of the netgraph bridging is to make it look as if the packets are all coming in off one interface. Theoretically the bridging code should be attached to only one 'upper' part of a driver and all packets should arrive at higher levels, looking as if they have all come in through that one interface. The other interfaces in the bridge will never receive anything because their input has been diverted. To the system it should look as if the entire bridged network is on that one interface. If this is not the case then we need to fix the bridging code so that it is true, rather than clutter up higher level code trying to account for a bug in the lower code. So how can an incoming packet look like it is not coming from that single interface? 1/ ifnet pointer. The function ng_ether_rcv_upper() adjust this, so that's not the problem. 2/ rcv interface MAC address. This is stripped off before arp gets it (also in ng_ether_rcv_upper()). 3/ the tha[] or sha[] fields may contain a MAC address for some other interface. (depending on how the remote mechine fills out those fields), but our outgoing packets should have the MAC address of the interface we have selected as out main interface, independent of which interface it actually goes out of, (unless the hardware over-writes it). so even that should point to the single interface. The other interfaces should (maybe) beb ifconfigged 'UP' but they should not have IP addresses assigned tp them, as they are being slaved from the main interface by the ng_bridging code so everything comes and goes via that one. so I'm slightly confused as to what problem this solves. (I'm not saying there isn't one, just that I con't figure out what it is). Everything should act as if there is just one interface when netgraph bridging is turned on. DocWilco Date: Mon, 29 Jan 2001 08:20:01 -0800 (PST) To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Re: kern/24720: Bridging code does not always check activation (w/patch) Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Thank you very much for your problem report. It has the internal identification `kern/24720'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=24720 Category: kern Responsible:freebsd-bugs Synopsis: Bridging code does not always check activation (w/patch) Arrival-Date: Mon Jan 29 08:20:01 PST 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
Once we have an extensible facility for mount options, you will be able to say: mount -t devfs devfs /home/jail/dev ( cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ) mount -u -o nonewdev /home/jail/dev Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It seems that "read my lips: no new devices" should be an option you can set from the very initial mount so that people can't also figure out how to get root, remove a /dev entry and replace it with one of their own. Come to think of it, there should also be a -o staticdev option to disallow *any* changes after the initial mount. That would make some of our more paranoid sysadmins happy. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Jordan Hubbard writes: Once we have an extensible facility for mount options, you will be able to say: mount -t devfs devfs /home/jail/dev ( cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ) mount -u -o nonewdev /home/jail/dev Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It seems that "read my lips: no new devices" should be an option you can set from the very initial mount so that people can't also figure out how to get root, remove a /dev entry and replace it with one of their own. Come to think of it, there should also be a -o staticdev option to disallow *any* changes after the initial mount. That would make some of our more paranoid sysadmins happy. That's called "mount -o ro" :-) I have not finalized the workings of the options, right now we have a 32-bit bitmap of mountoptions and they're all used up, and I don't have the time and bikeshedcarpenter hours to design a new mount option implementation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for non-netgraph bridge code worthy of attention forpeople experimenting with bridging setups (including ng_bridge)
At 00:48 3-2-01 -0800, Julian Elischer wrote:
"Rogier R. Mulhuijzen" wrote:
I found this while experimenting with both "legacy" bridge and ng_bridge.
The bridging code doesn't check its activation everywhere so when I started
using an ng_bridge node I started getting weird errors.
Patch is rather simple, can someone submit this?
I'm a litle confused when I look at this patch.
I think this is the wrong fix.
I see that you are accounting for packets coming in on two interfaces,
but the aim of the netgraph bridging is to make it look as if the
packets are all coming in off one interface. Theoretically the
bridging code should be attached to only one 'upper' part of a driver
and all packets should arrive at higher levels, looking as if they have
all come in through that one interface. The other interfaces in the bridge
will never receive anything because their input has been diverted. To the
system it should look as if the entire bridged network is on that one
interface.
If this is not the case then we need to fix the bridging code so that
it is true, rather than clutter up higher level code trying to
account for a bug in the lower code.
I found out this bug while using ng_bridge with BRIDGE in the kernel but
turned off with the sysctl.
Like I say in the problem report, this could easily be true if you take 2
NICs and wire them both up to the same switch, each using a different IP.
(Something we do at QuakeCon for instance. We run a lot of servers per box,
so we spread them out over 3 IPs, each with it's own NIC. Worked very
well). Netgraph has nothing to do with this. I'm just warning people who
are experimenting with the netgraph bridge because they will probably still
have BRIDGE in their kernel.
Let's run through this example of 2 NICs. Let's say I have BRIDGE in the
kernel. I would not want to enable bridging in this case, because I would
get a packet storm because of the loop between the machine and the switch.
So I turn it off. But the checks for incoming interface are still switched
off in the ethernet code. Checks that ARE executed when compiling without
BRIDGE. NIC1 has 10.1.1.2 and NIC2 10.1.1.3. An ARP request is sent for
10.1.1.2, and since it's a broadcast it will arrive on both NIC1 and NIC2.
Without the checks for what interface a packet came in on, the kernel will
send 2 ARP replies, one saying 10.1.1.3 is on NIC1, the other that 10.1.1.3
is on NIC2. The last ARP reply to be sent will be used by the other
machines on the network. Now with switches, they will probably handle
broadcast packets the same way each time, so the same NIC on our machine
will always get the ARP after the other got it. So the same NIC will always
win the battle over an IP, resulting in ALL traffic for the machine, no
matter what IP it was sent to, to go over a single NIC. That's a BAD(tm) thing.
Now if you compare the code that my patch effects from before and after the
patch you will see the following changes:
original code:
blabla();
#ifndef BRIDGE
doCheck();
#endif
dumDeDum();
my code
blabla();
#ifdef BRIDGE
if (do_bridge) {/* signifies whether bridging is switched on
or off by the sysctl */
#else
{
#endif
doCheck();
}
dumDeDum();
This will make the ethernet code behave EXACTLY the same when bridging is
switched off with the sysctl and when BRIDGE is NOT compiled into the kernel.
Now, on the netgraph stuff.
So how can an incoming packet look like it is not coming from that single
interface?
1/ ifnet pointer. The function ng_ether_rcv_upper() adjust this, so that's
not the problem.
2/ rcv interface MAC address. This is stripped off before arp gets it
(also in ng_ether_rcv_upper()).
3/ the tha[] or sha[] fields may contain a MAC address for
some other interface. (depending on how the remote mechine fills out
those fields), but our outgoing packets should have the MAC address
of the interface we have selected as out main interface, independent of
which interface it actually goes out of, (unless the hardware
over-writes it). so even that should point to the single interface.
The other interfaces should (maybe) beb ifconfigged 'UP' but they should
not have IP addresses assigned tp them, as they are being slaved from
the main interface by the ng_bridging code so everything comes and
goes via that one.
so I'm slightly confused as to what problem this solves.
(I'm not saying there isn't one, just that I con't figure out what it is).
Everything should act as if there is just one interface when netgraph
bridging is turned on.
Exactly if there's just one interface when netgraph bridging is on. Why?
Why just one interface? Now that my kernel is patched to behave like BRIDGE
wasn't compiled in when I switch it off I can include the upper's of
multiple interfaces in a single netgraph bridge.
If you think about it, this should not even be a problem.
Look at this diagram
Re: DEVFS
In article [EMAIL PROTECTED] you wrote: With devfs "default" in -current, I have a question about permissions. I know that rc.devfs will set up custom permissions at boot... But what about a device that detaches? When you re-attach, it goes back to the default permissions. This is a bit annoying; is there a workaround for it? Should this be handled by something that does the re-attaching? At least for the USB devices this can be done with the 'usbd' daemon. N.Dudorov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel hackers, please review.
Hi Please review the patch at http://people.freebsd.org/~markm/no_lock_h.diff. the idea is to remove sys/*/include/lock.h. I tested it with the usual i386 stuff, and it is known to break the cy driver because of the COM_(UN)LOCK macros (which is another issue). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
reading /dev/dsp crashes system
I just installed cvsupped and installed a new worldkernel at 3feb2000. Everything works fine, but reading /dev/dsp (cat /dev/dsp e.g.) gives some thousands of bytes output, but then totally crashes the system; it doesn't even break to the debugger when pressing Ctrl-Alt-Esc. It worked fine on my worldkernel from end december. - Willem cat /dev/sndstat gives: FreeBSD Audio Driver (newpcm) Feb 3 2001 12:56:43 Installed devices: pcm0: Yamaha DS-1E (YMF744) at memory 0xfedf8000 irq 9 (4p/2 channels duplex) Dmesg output about sound device: pcm0: Yamaha DS-1E (YMF744) port 0xf08c-0xf08f,0xf0c0-0xf0ff mem 0xfedf8000-0xfedf irq 9 at device 13.0 on pci0 And the obligatory uname -a output: FreeBSD jeremy.dyn.dhs.org 5.0-CURRENT FreeBSD 5.0-CURRENT #14: Sat Feb 3 12:48:10 CET 2001 [EMAIL PROTECTED]:/usr/src/.CURRENT/src/sys/compile/JEREMY i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for non-netgraph bridge code worthy of attentionforpeople experimenting with bridging setups (including ng_bridge)
"Rogier R. Mulhuijzen" wrote: [explanation] ok I understand now... I thought you were saying that the netgraph code was acting differently to how I belive it should act. Exactly if there's just one interface when netgraph bridging is on. Why? Why just one interface? Now that my kernel is patched to behave like BRIDGE wasn't compiled in when I switch it off I can include the upper's of multiple interfaces in a single netgraph bridge. sure you can. that isn't a problem. It would be a 'brouter' bridging non IP protocols and routing IP. If you think about it, this should not even be a problem. Look at this diagram http://www.bsdchicks.com/bridge-examples.gif (my apologies to everyone who can't look at graphical stuff) ok I understan.. my question is: Do you know the girl on http://www.bsdchicks.com/ and is she single? :-) It should be valid.. and I start to see your point. by adding the checks back in (or compiling without BRIDGE) you can have both interfaces What is the difference between figures 1 and 2? Except that one uses a switch, and the other uses just a FreeBSD box. yep The way packets travel is almost identical. Why wouldn't it be a valid setup? Another possibility would be to make a change to the netgraph bridge code so that it only delivers a broadcast packet to ONE local 'upper' hook. You say that interfaces included in the ng_bridge should not have their upper's included as well, except for one. I didn't mean that they COULDN'T but only that they didn't NEED it That's all fine for a static setup, but I'm dealing with a setup where I have a box that's a router between 2 networks, but sometimes needs to be a bridge as well. If I don't include the upper for one of the interfaces, outgoing packets on that interface will not pass my netgraph bridge, resulting in returning packets to be sent to all hooks on the bridge. I could of course hook my upper to a hole node, but then I'd have to move it's IP to the other interface. When I nuke the bridge I'd have to move it back. Why do that if including the upper in the bridge does the trick. Right now my FreeBSD box is routing between 3 networks and sometimes even bridging between all 3 and it works perfectly. Using netgraph or the other bridging? I presume Netgraph. I don't see any reason why multiple uppers can't be included. neither do I, In fact I recommented it to someone yesterday. But like I said, my patch has nothing to do with netgraph. When net.link.ether.bridge == 0 the kernel should behave like a kernel that doesn't have BRIDGE compiled in it. That's currently not the case and my patch fixes that. OK I will commit it. DocWilco -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for non-netgraph bridge code worthy of attentionforpeople experimenting with bridging setups (including ng_bridge)
ok I understand now... I thought you were saying that the netgraph code was acting differently to how I belive it should act. Nope that was the legacy bridge. Exactly if there's just one interface when netgraph bridging is on. Why? Why just one interface? Now that my kernel is patched to behave like BRIDGE wasn't compiled in when I switch it off I can include the upper's of multiple interfaces in a single netgraph bridge. sure you can. that isn't a problem. It would be a 'brouter' bridging non IP protocols and routing IP. If you think about it, this should not even be a problem. Look at this diagram http://www.bsdchicks.com/bridge-examples.gif (my apologies to everyone who can't look at graphical stuff) ok I understan.. my question is: Do you know the girl on http://www.bsdchicks.com/ and is she single? :-) Hahahaha, I don't have a clue who she is, and I'd love to know too =) It should be valid.. and I start to see your point. by adding the checks back in (or compiling without BRIDGE) you can have both interfaces Exactly What is the difference between figures 1 and 2? Except that one uses a switch, and the other uses just a FreeBSD box. yep The way packets travel is almost identical. Why wouldn't it be a valid setup? Another possibility would be to make a change to the netgraph bridge code so that it only delivers a broadcast packet to ONE local 'upper' hook. I wouldn't do that. You'd be adding behaviour that people wouldn't expect, and make it a messy unlogical thing. If people want it delivered on one upper hook, they should include just that one hook. Why make "user friendly" logic that makes it complicated and bothersome for people who want to do more than just the standard things. You say that interfaces included in the ng_bridge should not have their upper's included as well, except for one. I didn't mean that they COULDN'T but only that they didn't NEED it Eek. Misunderstood, my apologies. Right now my FreeBSD box is routing between 3 networks and sometimes even bridging between all 3 and it works perfectly. Using netgraph or the other bridging? I presume Netgraph. You are correct. Because I also have my uplink to the internet and I don't want packets "leaking" out to there. My provider might want to start wondering what all these subnets are etc. 2 of the three networks are even on the other side of tunnels built with vtun to Linux and other FreeBSD boxes. Those other networks are also linked to more. Among other things we can now play IPX games over the internet without any hassle =) But like I said, my patch has nothing to do with netgraph. When net.link.ether.bridge == 0 the kernel should behave like a kernel that doesn't have BRIDGE compiled in it. That's currently not the case and my patch fixes that. OK I will commit it. Thanks. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED] Jordan Hubbard writes: : Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" : and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It : seems that "read my lips: no new devices" should be an option you can : set from the very initial mount so that people can't also figure out : how to get root, remove a /dev entry and replace it with one of their : own. Come to think of it, there should also be a -o staticdev option : to disallow *any* changes after the initial mount. That would make : some of our more paranoid sysadmins happy. My concern is that I usually know what devices I want (/dev/null, /dev/zero, /dev/tty). That makes it harder to delete all of them not on the list. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Jordan Hubbard writes: : Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" : and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It : seems that "read my lips: no new devices" should be an option you can : set from the very initial mount so that people can't also figure out : how to get root, remove a /dev entry and replace it with one of their : own. Come to think of it, there should also be a -o staticdev option : to disallow *any* changes after the initial mount. That would make : some of our more paranoid sysadmins happy. My concern is that I usually know what devices I want (/dev/null, /dev/zero, /dev/tty). That makes it harder to delete all of them not on the list. I have seriously been thinking about some way to say something like mount -t devfs -o jailset /home/jail/dev but an elegant implementation evades me at this moment. And again, it hinges on an extensible set of mount options. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Warner Losh write s: In message [EMAIL PROTECTED] Jordan Hubbard writes: : Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" : and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It : seems that "read my lips: no new devices" should be an option you can : set from the very initial mount so that people can't also figure out : how to get root, remove a /dev entry and replace it with one of their : own. Come to think of it, there should also be a -o staticdev option : to disallow *any* changes after the initial mount. That would make : some of our more paranoid sysadmins happy. My concern is that I usually know what devices I want (/dev/null, /dev/zero, /dev/tty). That makes it harder to delete all of them not on the list. I have seriously been thinking about some way to say something like mount -t devfs -o jailset /home/jail/dev but an elegant implementation evades me at this moment. As bizzare as it sounds, I like Julian's hack for populating this stuff... ie: use a hard link to propagate nodes to the jailed /dev. eg: mount -t devfs -o empty /home/jail/dev ln /dev/null /home/jail/dev/null ln /dev/zero /home/jail/dev/zero ... mount -u -o ro /home/jail/dev It solves several problems, but is kinda odd as it involves a cross-filesystem hard link. This is another way oround the "oops, I didn't mean to rm /dev/null" - ie: mount -t devfs /mnt ln /mnt/null /dev umount /mnt The VOP_LINK() stuff has access to the source and destination, so it doesn't have to guess what do do on incomplete information (eg: fake major number). On the other hand... Suppose whiteouts were implemented... mount -t devfs -o empty /home/jail/dev cd /home/jail/dev rm -W null zero log mount -u -o ro /home/jail/dev ie: start with the initial state as "whiteouts on everything" and then selectively remove the whiteout for things you actually want... Then freeze it by flipping on the readonly bit. And again, it hinges on an extensible set of mount options. Yeah. Maybe pass in arbitary strins "empty" instead of trying to convert everything to a flag bit? I've been bothered about this for a while. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
I have seriously been thinking about some way to say something like mount -t devfs -o jailset /home/jail/dev but an elegant implementation evades me at this moment. As bizzare as it sounds, I like Julian's hack for populating this stuff... ie: use a hard link to propagate nodes to the jailed /dev. eg: mount -t devfs -o empty /home/jail/dev ln /dev/null /home/jail/dev/null ln /dev/zero /home/jail/dev/zero ... mount -u -o ro /home/jail/dev It solves several problems, but is kinda odd as it involves a cross-filesystem hard link. unwhiteout(2) has more promise I think. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED] Peter Wemm writes: : As bizzare as it sounds, I like Julian's hack for populating this stuff... : ie: use a hard link to propagate nodes to the jailed /dev. : : eg: mount -t devfs -o empty /home/jail/dev : ln /dev/null /home/jail/dev/null : ln /dev/zero /home/jail/dev/zero : ... : mount -u -o ro /home/jail/dev But you can't do hard links accross file systems. Or is that a hack of devfs to allow it, and if so does that create any other security problems. Recall the security implications of having procfs's 'file' file. He made a hard link to the file in question, and exposed many different classes of problem: unwanted disclosure, failure to take into account directory permissions, the ability to hard link to the file and execute it later (bad for setuid programs), etc. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Peter Wemm writes: : As bizzare as it sounds, I like Julian's hack for populating this stuff... : ie: use a hard link to propagate nodes to the jailed /dev. : : eg: mount -t devfs -o empty /home/jail/dev : ln /dev/null /home/jail/dev/null : ln /dev/zero /home/jail/dev/zero : ... : mount -u -o ro /home/jail/dev But you can't do hard links accross file systems. Or is that a hack of devfs to allow it, [...] Yes, it was a hack, and it will not be hacked that way in my DEVFS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message 14760.981228917@critter Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], Warner Losh writes: : In message [EMAIL PROTECTED] Peter Wemm writes: : : As bizzare as it sounds, I like Julian's hack for populating this stuff... : : ie: use a hard link to propagate nodes to the jailed /dev. : : : : eg: mount -t devfs -o empty /home/jail/dev : : ln /dev/null /home/jail/dev/null : : ln /dev/zero /home/jail/dev/zero : : ... : : mount -u -o ro /home/jail/dev : : But you can't do hard links accross file systems. Or is that a hack : of devfs to allow it, [...] : : Yes, it was a hack, and it will not be hacked that way in my DEVFS. I seem to recall talking to you about having symbolic links in your devfs mean something "special" as a way around this problem. No that was another, and probably too avant garde idea Julian and I have discussed: Basically device-drivers create devices in a private namespace, in /dev you link from the filesystem namespace to the private namespace with a kind of symbolic link. It has too many "issues" with standards and VOP's to be viable right now. Doing straight symlinks would not work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sys/queue.h API cleanup patch.
From: "Poul-Henning Kamp" [EMAIL PROTECTED] I have created a patch which goes a long way to clean up the the usage of the sys/queue.h API. The patch is generated automatically and the objectfiles are identical if line numbers are preserved by breaking style(9). You can find the script and the patch here: http://phk.freebsd.dk/patch Index: netinet/fil.c This is part of ipfilter. Ipfilter #ifdef's usage of sys/queue.h depending on the OS and OS revision. If we are going to make queue changes to it, we may as well also rip out the #ifdef's around queue usage based on other OS's and OS revisions. - Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message 14918.981230622@critter Poul-Henning Kamp writes:
: Doing straight symlinks would not work.
OK.
The other idea that I had was a cpdev. It would be like a templated
mknod. It would stat the first argument and do a mknod with the
st_rdev from the stat, eg:
#include err.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
int
main(char *argv[], int argc)
{
struct stat sbuf;
if (argc != 3)
errx(1, "usage: cpdev src dst");
if (stat(argv[1], sbuf))
err(1, "stat");
if (!S_ISCHR(sbuf.st_mode))
errx(1, "source must be a character device");
if (mknod(argv[2], sbuf.st_mode, sbuf.st_rdev))
err(1, "mknod");
exit(0);
}
This would mean we could export whatever we wanted from the kernel and
something like this would preserve it. It would mean allowing mknodo
n non-readonly devfs mounts. If there was a cheap way to determine
if the rdev was legitimate, it would be the best way to go. However,
that's the rub with this solution: we need to keep a table of devices
(like major numbers today and export them as major numbers) or we need
to know with certainty that a pointer is good, which traditionally has
had its share of security problems. Well, I suppose that the major
number thing could be a special case of returning a hash as well, but
that still requires a kernel table of some flavor.
Notice I don't bother with major/minor numbers at all, but just use
the raw rdev (which I hope is the right dev to use, since I think
st_dev is the device the filesystem is mounted on) so it doesn't
matter what we export as long as we can swallow what we export.
Of course this does assume that all devfs instances export the same
cookies for the same device.
Warner
P.S. I do hope someone will tell me if this is becoming too
bikeshedish.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : At least for the USB devices this can be done with the : 'usbd' daemon. And pccardd can handle this for OLDCARD users. NEWCARD users will need to cope until something comes alone :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message 14918.981230622@critter Poul-Henning Kamp writes: : Doing straight symlinks would not work. OK. The other idea that I had was a cpdev. It would be like a templated mknod. It would stat the first argument and do a mknod with the st_rdev from the stat, eg: It's really very simple, if I get my way, this will be possible: # rm /dev/null # echo 'OOPS!' # rm -W /dev/null # ls -l /dev/null crw-rw-rw- 1 root wheel2, 2 3 Feb 21:25 /dev/null # mount -t devfs devfs /home/jail/dev # cd /home/jail/dev # rm -f * # rm -W null zero tty console # ls -l crw--- 1 phk wheel0, 0 2 Feb 01:09 console drwxr-xr-x 2 root wheel 0 2 Feb 01:06 fd crw-rw-rw- 1 root wheel2, 2 3 Feb 21:25 null crw-rw-rw- 1 root wheel1, 0 3 Feb 17:27 tty crw-rw-rw- 1 root wheel2, 12 1 Jan 1970 zero # P.S. I do hope someone will tell me if this is becoming too bikeshedish. It is :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sys/queue.h API cleanup patch.
Why not the 'audit' list which is what audit is for I thought? Other than if_wx which breaks cstyling, looks okay to me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI S1
Has anyone see acpi S1 mode realy work? Rasa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCI bus code SMC9432 behaviour
Hi! I got into a following problem with subj: During boot process, the card can be in power down mode. This can be cause MEMEN and PORTEN bits not set up correctly (set to 0) during boot. This bits not set will cause no resources for this device, thus later a bus_alloc_resource() call will fail. I succeed to with adding resources manualy by calling bus_set_resource(), but it seems to me a wrong idea. I supposed the pci code analyze that driver sets/clears PORTEN or MEMEN bit, and thus add/remove appropriate resources... This wont be difficult. If you say this is a good idea, i can provide a patch myself, though i haven't thouched the pci code before. Good luck! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ACPI S1
On 03-Feb-01 Rasa Karapandza wrote: Has anyone see acpi S1 mode realy work? Sort of. It works on my laptop if I'm in X with my wavelan plugged in. At a console with no devices plugged in it will immediately resume after suspend. Rasa -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
doFS.sh should obey MDDEVICE if available
src/release/scripts/doFS.sh rev. 1.6 doesn't consider MDDEVICE variable
(formaly, VNDEVICE). Here is a sample fix to use MDDEVICE variable to
configure md -- trivial, add '-u' option if MDDEVICE is already defined.
-- -
Makoto `MAR' MATSUSHITA
Index: doFS.sh
===
RCS file: /pub/cvsup/FreeBSD.cvs/src/release/scripts/doFS.sh,v
retrieving revision 1.29
diff -c -r1.29 doFS.sh
*** doFS.sh 2001/01/31 22:58:39 1.29
--- doFS.sh 2001/02/03 23:16:51
***
*** 37,43
awk 'BEGIN {printf "%c%c", 85, 170}' |\
dd of=${FSIMG} obs=1 seek=510 conv=notrunc 2/dev/null
! MDDEVICE=`mdconfig -a -t vnode -f ${FSIMG}`
if [ ! -c /dev/${MDDEVICE} ] ; then
if [ -f /dev/MAKEDEV ] ; then
( cd /dev sh MAKEDEV ${MDDEVICE} )
--- 37,47
awk 'BEGIN {printf "%c%c", 85, 170}' |\
dd of=${FSIMG} obs=1 seek=510 conv=notrunc 2/dev/null
! if [ "x${MDDEVICE}" != "x" ] ; then
! mdconfig -a -t vnode -f ${FSIMG} -u ${MDDEVICE}
! else
! MDDEVICE=`mdconfig -a -t vnode -f ${FSIMG}`
! fi
if [ ! -c /dev/${MDDEVICE} ] ; then
if [ -f /dev/MAKEDEV ] ; then
( cd /dev sh MAKEDEV ${MDDEVICE} )
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: doFS.sh should obey MDDEVICE if available
On 03-Feb-01 Makoto MATSUSHITA wrote: src/release/scripts/doFS.sh rev. 1.6 doesn't consider MDDEVICE variable (formaly, VNDEVICE). Here is a sample fix to use MDDEVICE variable to configure md -- trivial, add '-u' option if MDDEVICE is already defined. But you shouldn't need this. The only reason for the old VNDEVICE was because the release process couldn't automatically find an unused device to use, so it had to have help if vn0 is used. The current method always finds an unused device to use, so the old VNDEVICE-style hack is no longer needed. There's no point to setting an explicit device to use. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: doFS.sh should obey MDDEVICE if available
jhb The current method always finds an unused device to use, so the
jhb old VNDEVICE-style hack is no longer needed. There's no point to
jhb setting an explicit device to use.
But I want to ensure that all used md(4) devices is unconfigured after
it is used.
Imagine you run 'make release' for your own release. If something is
trouble in doFS.sh ('kernel size exceeds 1.44MB floppy size' is a
typical example), make will exit without umounting /mnt and
unconfigureing /dev/mdX, where X is dynamically allocated (and no way
to know what X is outside of doFS.sh). If I can say 'doFS.sh, your md
device number is X', it's obviously easy to umount /mnt and
unconfigure md devices after the script runs.
My mother tolds me that I should put away my toys after I play with
them, so I want to do a sure way to unconfigure md device.
BTW, how many md devices can we configure at the same time? What's
happen if a file of md's backing store is removed?
-- -
Makoto MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: doFS.sh should obey MDDEVICE if available
On 04-Feb-01 Makoto MATSUSHITA wrote:
jhb The current method always finds an unused device to use, so the
jhb old VNDEVICE-style hack is no longer needed. There's no point to
jhb setting an explicit device to use.
But I want to ensure that all used md(4) devices is unconfigured after
it is used.
Imagine you run 'make release' for your own release. If something is
trouble in doFS.sh ('kernel size exceeds 1.44MB floppy size' is a
typical example), make will exit without umounting /mnt and
unconfigureing /dev/mdX, where X is dynamically allocated (and no way
to know what X is outside of doFS.sh). If I can say 'doFS.sh, your md
device number is X', it's obviously easy to umount /mnt and
unconfigure md devices after the script runs.
If it is still mounted, you can see the device by just typing 'mount' to get a
list of mounted filesystems. You will have something like:
/dev/md0 on /mnt (ufs, local)
Also, I think that this isn't the right fix to a bigger problem. Instead, it
shouldn't be hard to get a list of configured devices out of mdconfig via an
ioctl on /dev/mdctl. This would be the right fix, as it would fix the general
case problem you describe, not just one instance of it. mdconfig wont' be able
to tell you what file it is attached to by filename, but it should be able to
ask /dev/mdctl for a list of devices and report at least the type of each
device (swap, file, etc.).
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
On Sat, Feb 03, 2001 at 12:32:50PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Peter Wemm writes: : As bizzare as it sounds, I like Julian's hack for populating this stuff... : ie: use a hard link to propagate nodes to the jailed /dev. : : eg: mount -t devfs -o empty /home/jail/dev : ln /dev/null /home/jail/dev/null : ln /dev/zero /home/jail/dev/zero : ... : mount -u -o ro /home/jail/dev But you can't do hard links accross file systems. Actually, you've always been able to do things like this. For example: ln /proc/curproc/file /test on a 3.X machine will produce a hard link to ln in / - it doesn't work any more 'cos /proc/curproc/file is now a soft link. I presume the same thing works with fdescfs. This is actually one nice feature Linux procfs has: I once was asked to look at a Linux box someone had broken into. They'd deleted all the files in /var/log, but hadn't HUPed syslogd - so I just hard linked them all back into place again. Not an every day use, but... David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: doFS.sh should obey MDDEVICE if available
Oops, sorry that From: address was different from the first email... jhb Instead, it shouldn't be hard to get a list of configured devices jhb out of mdconfig via an ioctl on /dev/mdctl. This would be the jhb right fix, as it would fix the general case problem you describe, jhb not just one instance of it. Agreed. We can also detect 'umounted, but configured md devices' with the output of mount(8) and a list mentioned above. jhb mdconfig wont' be able to tell you what file it is attached to by jhb filename, but it should be able to ask /dev/mdctl for a list of jhb devices and report at least the type of each device (swap, file, jhb etc.). It maybe a stupid question (sorry I have few knowledge about kernel internal)... Can't we add a space for filename in the structure of md device? It would be wonderful if 'mdconfig -l' says: unit mountedtypeoption 0/tmp malloc -s=65535,reserve 1none file/home/matusita/fdimage 2none swapnone or something like that. If we have a configulation file for mdconfig(8), this output will be the same of its file format. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel trap 26 panic
lpt gives an instant panic with sources from this afternoon (3 Feb 01 pst). So far, I can boot the system if I disable lpd in /etc/rc.conf. If I start lpd from the command, I get %lpd stray irq 7 stray irq 7 stray irq 7 stray irq 7 kernel trap 26 with interrupts disabled panic: mutex sched lock recursed at /usr/src/sys/kern/kern_synch.c:918 kargl[202] uname -a FreeBSD C456086-A.bllvu1.wa.home.com 5.0-CURRENT FreeBSD 5.0-CURRENT\ #3: Sat Feb 3 13:59:49 GMT 2001 [EMAIL PROTECTED]\ :/usr/obj/usr/src/sys/C456086-A i386 I have a crash dump. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doFS.sh should obey MDDEVICE if available
Also, I think that this isn't the right fix to a bigger problem. Instead, it shouldn't be hard to get a list of configured devices out of mdconfig via an ioctl on /dev/mdctl. This would be the right fix, as it would fix the general case problem you describe, not just one instance of it. mdconfig wont' be able to tell you what file it is attached to by filename, but it should be able to ask /dev/mdctl for a list of devices and report at least the type of each device (swap, file, etc.). I think I can do this, possibly with a little help. md(4) keeps a list of md_s structures. From these, I think you can fill in the majority (if not all) of the fields in an md_ioctl structure. I tried this, and I can successfully return one almost-filled md_ioctl structure. If someone can suggest a method for returning an arbitrary number of md_ioctl's (a list), I think I may be able to implement this. Any pointers? Thanks Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Watch your devfs permissions in driver make_dev calls
On Friday, 2 February 2001 at 20:10:10 -0800, Peter Wemm wrote: Robert Watson wrote: crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci This one may appear harmless, but it is not. It is trivially easy to create an alignment fault (fatal on an alpha) with the userland pciconf tool. We must not allow this to be used by users until the kernel part is fixed. Eg: try this on an alpha: pciconf -r -l pci0:x:x 0x3 - ie: read a longword at byte offset 3 in configuration space.. kaboom! This looks like a separate issue. Presumably you can do this as root as well. pciconf should check the parameters. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: kernel trap 26 panic
On 04-Feb-01 Steve Kargl wrote: lpt gives an instant panic with sources from this afternoon (3 Feb 01 pst). So far, I can boot the system if I disable lpd in /etc/rc.conf. If I start lpd from the command, I get %lpd stray irq 7 stray irq 7 stray irq 7 stray irq 7 kernel trap 26 with interrupts disabled panic: mutex sched lock recursed at /usr/src/sys/kern/kern_synch.c:918 kargl[202] uname -a FreeBSD C456086-A.bllvu1.wa.home.com 5.0-CURRENT FreeBSD 5.0-CURRENT\ #3: Sat Feb 3 13:59:49 GMT 2001 [EMAIL PROTECTED]\ :/usr/obj/usr/src/sys/C456086-A i386 I have a crash dump. The ppbus does painful things with its interrupt handlers. This is a known problem and on the todo list, just not fixed yet. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
