Re: What is VT_TFS?
Terry Lambert wrote: Zhihui Zhang wrote: What is the file system that uses VT_TFS in vnode.h? Is it still available on FreeBSD? Thanks. Julian added it for TRW Financial Services; the first public reference machine for 386BSD (which later became FreeBSD and NetBSD) was ref.tfs.com. TRW supported a lot of the early 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw in and had us change the version number from 0.1 to 1.0 to make it a bit easier to sell. The version numbers have been bloating ever since... I think you are thinking of other stuff I did at TFS, (we had something similar) but never committed here.. this was actually done in the following commit: --- Revision 1.36 / (download) - annotate - [select for diffs], Thu Oct 17 17:12:04 1996 UTC (4 years, 10 months ago) by jkh Branch: MAIN CVS Tags: RELENG_2_2_BP Branch point for: RELENG_2_2 Changes since 1.35: +2 -2 lines Diff to previous 1.35 (colored) Some very small changes to support Netcon's TFS filesystem. These patches were formerly applied by the Netcon installer before rebuilding your kernel. -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What is VT_TFS?
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Terry Lambert writes: Zhihui Zhang wrote: What is the file system that uses VT_TFS in vnode.h? Is it still available on FreeBSD? Thanks. Julian added it for TRW Financial Services; And "TFS" means "Truly evil File System" :-) not of my doing.. see other email (cvsweb is your friend) It should be nuked now of course. I have no idea if they (the people who added it) are still working on that filesystem. v_tag is only a debugging aid and it should be replaced by a "const char *" instead so that we don't need to modify sys/vnode.h just to add a filesystem. AMEN -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysent in fork()
Evan Sarmiento wrote: Hey, I have a question about sysent. If a modification to a processes p-p_sysent and associated substructures are made, are the changes propagated through fork to children? Yes, for fork(). You probably wanted to ask about exec(), though... the answer for exec() is it uses the brand on the exec()'ed binary to decide which call table to use. This probably means that you are running into a problem with an unbranded Linux binary being run from another Linux binary... alternately, you might be confusing the path prefix lookup for branded binaries, which causes an path search to look in the /compat/linux directory before looking under /, if what is being run is a Linux binary. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: .so and threads, and stereo /dev/dsp, freebsd 4.3-stable.
Faried Nawaz wrote:
Next: the OSS plugin builds but doesn't seem to work properly. At
some point, it tries to set /dev/dsp to stereo, and fails:
tmp = 0;
if (shm-channels == 2)
tmp = 1;
rc = ioctl (audio_fd, SNDCTL_DSP_STEREO, tmp);
if (rc 0) {
perror (snd_dev);
Con_Printf (Could not set %s to stereo=%d, snd_dev, shm-chann
els);
close (audio_fd);
return 0;
}
I have a Creative 128 card which identifies itself as
pcm0: AudioPCI ES1373-8 port 0x6800-0x683f irq 10 at device 10.0 on pci0
What can I do here to make quakeforge use the sound card?
I've seen something like this before.
The cause was the sourd card being opened twice, and the second
open failing, without the programmer checking the open return
code in the second case.
The fix was to use the already open fd, instead of reopening
the card.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Promise ATA attaches UDMA66, but not UDMA33
It seems David Gilbert wrote: I've got a promise ATA-66 controller. According to it's bios screen, the hard drives attached to it are UDMA-4 and the two CD-type devices are UDMA-2. All four devices are attached with ATA-66 cabling. I also have hw.ata.atapi_dma=1 in loader.conf. I get the following probe: ad6: 39266MB IBM-DTLA-305040 [79780/16/63] at ata3-master UDMA66 ad7: 39266MB IBM-DTLA-305040 [79780/16/63] at ata3-slave UDMA66 acd0: DVD-ROM TOSHIBA DVD-ROM SD-M1502 at ata2-master using PIO4 acd1: CD-RW CD-W512EB at ata2-slave using PIO4 Is the driver possibly not recognising the UDMA2 state from the controller? The Promise controllers doesn't support ATAPI DMA, or at least the older ones didn't, and some require special code, however the newer ones (TX2) should support it. I have this on my list for the newer Promises, watch -current for when it hits the tree... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: signal handling descrpancy (FreeBSD oaf fix/Evolution)
David O'Brien wrote: Hi Hackers, et.al. The PIM Evolution, http://www.ximian.com/products/ximian_evolution/, does not run on FreeBSD. The authors have made a change so that it will. However, we would like to know if FreeBSD is the odd-man-out, or if the authors were lucky Evolution ran on Solaris and Linux. There's some oddity in FreeBSD's SIGCHLD handling. If you ignore the signal, it's supposed to magically reap when child processes exit, according to my copy of Go SOLO 2 (The Single UNIX Specification). FreeBSD makes you explicitly set the handler/mask the signal yourself. Technically, either way could be considered correct; there was a patch to -current that fixed FreeBSD; I'm not sure if it was MFC'ed to the 4.4 branch or not... There was a big discussion on -current about proper handling, if I recall correctly. FWIW, I opposed the change (which implied SA_CLDWAIT, I think, with no way to turn it off to get historical behaviour for programs which needed it). I hate POSIX signal handling... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC request (was Re: symlink(2) [Was: Re: tcsh.cat])
I comitted a fix to -current two months ago. It's still in my -stable tree... if Jordan gives the O.K., I will MFC it to -stable. -Matt Erm, sorry, but what does MFC mean here ? I see this term used a lot and I can even guess what it stands for, but I may get it incorrectly ... Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: general ethernet driver changes
Did you have opportunity to play with the soft interrupt coalescing we discussed? I was able to remove a third of the interrupt overhead from the Tigon III driver, using the approach we discussed at the user group meeting two months back. It looks to be a serious win... and it appears to be applicable to almost every driver you've written (it's about a 12 line change per driver). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC request (was Re: symlink(2) [Was: Re: tcsh.cat])
On Tue, 4 Sep 2001, Eugene L. Vorokov wrote: I comitted a fix to -current two months ago. It's still in my -stable tree... if Jordan gives the O.K., I will MFC it to -stable. -Matt Erm, sorry, but what does MFC mean here ? I see this term used a lot and I can even guess what it stands for, but I may get it incorrectly ... Merged From Current. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD and Athlon Processors
David O'Brien wrote: Well, since it didn't, I might as well explain the problem here too. There are at least two major problems with VIA chips: [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] Are you sure about that? I am. I was having data coruption in a terrable way when I added a 2nd IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. Are you sure it's not just a CMD640 IDE controller? They are known to have issues; Linux has a patch... FreeBSD used to, but I think it got yanked out, or was just turned off by default. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SO_REUSEPORT on unicast UDP sockets
Vladimir A. Jakovenko wrote: Hello! According to UNPv1 SO_REUSEPORT on UDP sockets can be used to bind more than one socket to the same port (even with same source ip address). But quick look on /sys/netinet/udp_usrreq.c function udp_input() shows that this will work as expected (data stream duplicate) only on multicast/broadcast local addresses. Please pay attention to the following code fragment comments: [ ... ] Is there still any real need in such backward compatibility? Can such functionality be added (fixed) with possibility to switch it off using sysctl or kernel-build option? I find such possibility realy useful at least for NetFlow data processing and believe that it would be useful for many UDP-based protocols. Bound UDP sockets have always been problematic; there's a lot of code out there that depnds on the historical behaviour for unicast, unfortunately, including a number of commercial applications that run on FreeBSD (e.g. Real Server). If you look at that code for any length of time, you will get to see it as an armpit: it's not a good place to stick your nose, and it tends to smell to high heaven. At my current job, I'm up to my elbows in it... Similarly, there are a number of bugs in the TCP sockets as well; specifically, there's a problem with all sockets being treated as being in the same collision domain, when doing automatic port assignment. This limits you to 65535 oubound TCP connections, even though you have multiple IP aliases on an interface (theoretically, you should get 64k connections per IP address, if you bind _not_ to IN_ADDR_ANY, but instead use a specific port, but the hash is broken). There's also another problem with the cloned route, in the case you get a redirect, since the clone is not properly updated (e.g. do a ping, get a redirect, and notice that you keep getting the redirect until you stop and restart the ping, after which you get the correct route record: there was a recent thread on this in -current, where someone ICMP'ed themselves to death using multiple Gigabit interfaces as unbonded non-VLAN equivalence routes). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: general ethernet driver changes
Did you have opportunity to play with the soft interrupt coalescing we discussed? Did this message just leak to a mailing list, or would you be able to expand this (or pass a pointer to mailing lists where this was discussed) ? thanks luigi I was able to remove a third of the interrupt overhead from the Tigon III driver, using the approach we discussed at the user group meeting two months back. It looks to be a serious win... and it appears to be applicable to almost every driver you've written (it's about a 12 line change per driver). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: What is VT_TFS?
Julian Elischer wrote: What is the file system that uses VT_TFS in vnode.h? Is it still available on FreeBSD? Thanks. Julian added it for TRW Financial Services; the first public reference machine for 386BSD (which later became FreeBSD and NetBSD) was ref.tfs.com. TRW supported a lot of the early 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw in and had us change the version number from 0.1 to 1.0 to make it a bit easier to sell. The version numbers have been bloating ever since... I think you are thinking of other stuff I did at TFS, (we had something similar) but never committed here.. this was actually done in the following commit: Hunh. I could have sworn that that was your baby... I guess I'm just remembering a conversation about the something similar. In any case, it's useful to let a VFS layer own its vnodes... so I'd leave it there: never know when you might need it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: general ethernet driver changes
Luigi Rizzo wrote: Did you have opportunity to play with the soft interrupt coalescing we discussed? Did this message just leak to a mailing list, or would you be able to expand this (or pass a pointer to mailing lists where this was discussed) ? Ignore the man behind the curtain... 8-) Seriously, it was at two BABUG (Bay Area BSD User's Group) meetings; no big secret. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Junior Kernel Hacker task: improve vnode-v_tag
Assignment: The v_tag element in struct vnode is a debugging aid, but unfortunately it is implemented in a way which means that adding a filesystem means modifying the definition in sys/vnode.h. Convert the v_tag to an const char * and have the filesystems put their name in there instead. The v_tag has been abused a few places, easily recognizable by the fact that the kernel should never inspect the value of v_tag. These places should be easily changeable to use the new representation. Please mark them with a big fat /*XXX: ABUSE OF v_tag */ comment. -- 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-hackers in the body of the message
Snmp problems
Hello, Since yesterday, when I do /usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.cfg It says: SNMP Error: no response received SNMPv1_Session (remote host: 127.0.0.1 [127.0.0.1].161) community: TMRTGCHO request ID: 1484981548 PDU bufsize: 8000 bytes timeout: 2s retries: 5 backoff: 1) at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName on [EMAIL PROTECTED]: at /usr/local/bin/mrtg line 1485 WARNING: Expected a number but got '' WARNING: Expected a number but got '' SNMP Error: no response received SNMPv1_Session (remote host: 127.0.0.1 [127.0.0.1].161) community: TMRTGCHO request ID: 1484981549 PDU bufsize: 8000 bytes timeout: 2s retries: 5 backoff: 1) at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 SNMPGET Problem for ifInOctets.2 ifOutOctets.2 sysUptime sysName on [EMAIL PROTECTED]: at /usr/local/bin/mrtg line 1485 WARNING: Expected a number but got '' WARNING: Expected a number but got '' ... It's very strange because I didn't modify anything on snmp configuration. Then I can't have trafic stats for my interfaces... I killed and restarted snmpd but no change. Anyone has got an idea ? Regards, Chojin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Snmp problems
Do your community string correct ? Do you change community string recently ? Do you configure [Target] tag in mrtg.conf point to correct MIB ? Chojin wrote: Hello, Since yesterday, when I do /usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.cfg It says: SNMP Error: no response received SNMPv1_Session (remote host: 127.0.0.1 [127.0.0.1].161) community: TMRTGCHO request ID: 1484981548 PDU bufsize: 8000 bytes timeout: 2s retries: 5 backoff: 1) at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName on [EMAIL PROTECTED]: at /usr/local/bin/mrtg line 1485 WARNING: Expected a number but got '' WARNING: Expected a number but got '' SNMP Error: no response received SNMPv1_Session (remote host: 127.0.0.1 [127.0.0.1].161) community: TMRTGCHO request ID: 1484981549 PDU bufsize: 8000 bytes timeout: 2s retries: 5 backoff: 1) at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 SNMPGET Problem for ifInOctets.2 ifOutOctets.2 sysUptime sysName on [EMAIL PROTECTED]: at /usr/local/bin/mrtg line 1485 WARNING: Expected a number but got '' WARNING: Expected a number but got '' ... It's very strange because I didn't modify anything on snmp configuration. Then I can't have trafic stats for my interfaces... I killed and restarted snmpd but no change. Anyone has got an idea ? Regards, Chojin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Snmp problems
Problems started since yesterday and last time I modified community and other things few weeks ago. When I try to cfgmaker, it displays the same errors. - Original Message - From: Kelvin Ng Chee Hoong [EMAIL PROTECTED] To: Chojin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 04, 2001 12:02 PM Subject: Re: Snmp problems Do your community string correct ? Do you change community string recently ? Do you configure [Target] tag in mrtg.conf point to correct MIB ? Chojin wrote: Hello, Since yesterday, when I do /usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.cfg It says: SNMP Error: no response received SNMPv1_Session (remote host: 127.0.0.1 [127.0.0.1].161) community: TMRTGCHO request ID: 1484981548 PDU bufsize: 8000 bytes timeout: 2s retries: 5 backoff: 1) at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 SNMPGET Problem for ifInOctets.1 ifOutOctets.1 sysUptime sysName on [EMAIL PROTECTED]: at /usr/local/bin/mrtg line 1485 WARNING: Expected a number but got '' WARNING: Expected a number but got '' SNMP Error: no response received SNMPv1_Session (remote host: 127.0.0.1 [127.0.0.1].161) community: TMRTGCHO request ID: 1484981549 PDU bufsize: 8000 bytes timeout: 2s retries: 5 backoff: 1) at /usr/local/lib/perl5/site_perl/5.005/SNMP_util.pm line 450 SNMPGET Problem for ifInOctets.2 ifOutOctets.2 sysUptime sysName on [EMAIL PROTECTED]: at /usr/local/bin/mrtg line 1485 WARNING: Expected a number but got '' WARNING: Expected a number but got '' ... It's very strange because I didn't modify anything on snmp configuration. Then I can't have trafic stats for my interfaces... I killed and restarted snmpd but no change. Anyone has got an idea ? Regards, Chojin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ipnat, ipf, ipfstat devices not configured
Hello, Since I recompiled my system and kernel (4.3-RELEASE) I can't use ipnat ipf and ipfstat: #ipnat /dev/ipnat: open: Device not configured #ipf -Fa -f /etc/ipf.rules open device: Device not configured ioctl(SIOCIPFFL): Bad file descriptor open device: Device not configured 2:ioctl(add/insert rule): Bad file descriptor 3:ioctl(add/insert rule): Bad file descriptor #ipfstat open: Device not configured I did all things needed as MAKEDEV all (done by mergemaster). There are all options unchanged in my kernel configuration file: options IPFILTER#ipfilter support options IPFILTER_LOG#ipfilter logging options IPFIREWALL options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT I don't understand why there is this problem. Anyone could help me ? Chojin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
subscriber incoming
subscribe freebsd-hackers _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote: | | Assignment: | | The v_tag element in struct vnode is a debugging aid, but unfortunately | it is implemented in a way which means that adding a filesystem means | modifying the definition in sys/vnode.h. | | Convert the v_tag to an const char * and have the filesystems put | their name in there instead. | | The v_tag has been abused a few places, easily recognizable by the fact | that the kernel should never inspect the value of v_tag. | These places should be easily changeable to use the new representation. | Please mark them with a big fat /*XXX: ABUSE OF v_tag */ comment. #include newbie_kernel_hacker_warning.h I've done a /cursory/ look over how this v_tag is used. I'm not sure this is a simple/clean as you propose, since this is used in the IS_LOCKING_VFS macro, as well as in union_subr.c... These uses /seem/ fairly significant due to the fact that the v_tag is being used to determine capabilities of the vnode in question. How should this be worked around? It would be fairly trivial to change v_tag to v_feature (or similar) then add the v_tag as you propose. I suggest this since those _tests_ for features should IMO not be done with a char[] operation, since that would (in my ignorant estimation) have a very negative effect on fs performance. Of course, my suggested v_feature hack would again require changing vnode.h for new features, but this is (assumedly) less frequent than modifying for file systems. I'll work on this this weekend, and (hopefully) follow thru with a patch. cheers. Brent -- Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing. -- Duane Allman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
In message [EMAIL PROTECTED], Brent Verner writes: On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote: | | Assignment: | | The v_tag element in struct vnode is a debugging aid, but unfortunately | it is implemented in a way which means that adding a filesystem means | modifying the definition in sys/vnode.h. | | Convert the v_tag to an const char * and have the filesystems put | their name in there instead. | | The v_tag has been abused a few places, easily recognizable by the fact | that the kernel should never inspect the value of v_tag. | These places should be easily changeable to use the new representation. | Please mark them with a big fat /*XXX: ABUSE OF v_tag */ comment. #include newbie_kernel_hacker_warning.h I've done a /cursory/ look over how this v_tag is used. I'm not sure this is a simple/clean as you propose, since this is used in the IS_LOCKING_VFS macro, as well as in union_subr.c... Well, that is just too bad, because IS_LOCKING_VFS is wrong then. The places which inspect v_tag will have to be changed to use strcmp() then... -- 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-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
On Tue, Sep 04, 2001 at 02:27:00PM +0200, Poul-Henning Kamp wrote: I've done a /cursory/ look over how this v_tag is used. I'm not sure this is a simple/clean as you propose, since this is used in the IS_LOCKING_VFS macro, as well as in union_subr.c... Well, that is just too bad, because IS_LOCKING_VFS is wrong then. That's what the line of comment above it said ;) /* * [dfr] Kludge until I get around to fixing all the vfs locking. */ Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Chris Costello wrote: On Friday, August 31, 2001, Michael Sinz wrote: I too have been hoping for (and building internal tools) that work this way. I really wish you could just do: open(nfs://server.name.dom/directory/file.txt) and have it work. That would be nice. (Replace the above with ftp: or http: or whatever other protocol would provide read and/or write access.) Anyway, I don't see it happening quickly but I don't see it as a bad thing and I would guess that it will eventually get to that point. (The network includes your local machine so why not) Whatever happened to not distinguishing different types of file systems from one another in pathnames? And are you suggesting that we add network overhead (I'd still imagine lo0 can't help speeding things up...) to file system accesses? What I was trying to say is that there is no reason that I should care if the file is local or not. Why should a program have to specifically offer support to edit that file from an FTP site. (EMACS and other editors have added transparent FTP support, but that was extra work for them) Just as the OS support having multiple storage devices and media and the software does not need to know if the file is on a SCSI or IDE disk or if it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if it is local or on the machine beside it or on the machine on the other side of the world? Now, the OS (from a technical level) should be smart enough to handle not doing actual NFS (or FTP or HTTP or whatever protocol) to its local disk when it can. (Sometimes going in via FTP to the local machine gets you in as a different user and thus gets you different access rights so the level of complexity is not always obviously trivial) Anyway, the point is that a file that I can access should be a file I can access via VI or MORE or EMACS or GREP or any other tool without having those tools each having FTP and HTTP and SSH support built in to them. The OS should handle it. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Paul Chvostek wrote: On Fri, Aug 31, 2001 at 02:15:09PM -0400, Michael Sinz wrote: I too have been hoping for (and building internal tools) that work this way. I really wish you could just do: open(nfs://server.name.dom/directory/file.txt) NAME amd - automatically mount file systems ... DESCRIPTION Amd is a daemon that automatically mounts filesystems whenever a file or directory within that filesystem is accessed. Filesystems are automati- cally unmounted when they appear to be quiescent. Ahh, but that assumes that your AMD configuration has all systems and mount points enumerated in it. Let me see - I think that 30gig drive may be big enough for that file :-) and have it work. That would be nice. (Replace the above with ftp: or http: or whatever other protocol would provide read and/or write access.) What you're looking for is a substitute open() function. Perhaps someone should just write a URI base library. Put it in the public domain, of course, so that all UR base is belong to us Ahh, but that does not address all software. Sure, edit all source and make the call to open() now be a call to uri_open()... Why bother making the OS deal with the issues involved? The reason the OS should (and could) is that it is the base from which all such services grow. Now, in a microkernel design (such as the previously mentioned HURD) there are ways to extend the filesystem to include new types (FTPFS is a great example of such a filter/expansion) but in FreeBSD (very much not microkernel) this then becomes an OS issue or a user-program issue. If it is in user space you end up with some have it and some don't and some have some subset which makes it really nasty. Can you imagine if there was an ide_open() to open files on IDE drives and a scsi_open() to open files on SCSI drives? Or a UFS_open() vs an ext2_open() vs an FFS_open()? Why would you then want a uri_open() vs regular open()? ahem Watch those puns - I could end up returning them unopened :-) -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD and Athlon Processors
Terry Lambert wrote: David O'Brien wrote: Well, since it didn't, I might as well explain the problem here too. There are at least two major problems with VIA chips: [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] Are you sure about that? I am. I was having data coruption in a terrable way when I added a 2nd IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. Are you sure it's not just a CMD640 IDE controller? They are known to have issues; Linux has a patch... FreeBSD used to, but I think it got yanked out, or was just turned off by default. I didn't think anybody used the CMD640 anymore (not since early Pentium days even). Anyway sys/pci/ide_pci.c still has the workaround for the CMD640, it's just not a kernel option anymore because FreeBSD automagically detects and installs the workaround now if you have one. -- \ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED] |\/ | ||/ _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gzipped crashdumps
John Polstra wrote: In article [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] wrote: Anyone else think this patch from NetBSD is worthwhile? Yes yes yes yes yes! That's 5 votes in favor of it already. :-) Add in another 50 here (the number of machines here that produce dumps in our test lab :-() -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Anyway, the point is that a file that I can access should be a file I can access via VI or MORE or EMACS or GREP or any other tool without having those tools each having FTP and HTTP and SSH support built in to them. The OS should handle it. Yes, this should be nice. There's a similar project for Linux here: http://ftpfs.sourceforge.net/ (FTP only). It would be amusing to port it into a KLD file. -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
What I was trying to say is that there is no reason that I should care if the file is local or not. You do need to know if the file is local or not. You need to know for security. You need to know because files behave differently on different machines. You need to know because file structures don't map from one machine to another. You need to know because differing protocols allow you do to very different things to files. You need to know because performance varies dramatically depending on where the file is located. Just as the OS support having multiple storage devices and media and the software does not need to know if the file is on a SCSI or IDE disk or if it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if it is local or on the machine beside it or on the machine on the other side of the world? The OS support of multiple device types exists because it is possible and reasonable to abstract each of those device types into a single virtual type. When this isn't possible or reasonable, it's not only difficult but *wrong* to abstract. There are way too many things you can do with a local file that you can't do with a remote file to allow this abstraction. Anyway, the point is that a file that I can access should be a file I can access via VI or MORE or EMACS or GREP or any other tool without having those tools each having FTP and HTTP and SSH support built in to them. The OS should handle it. No it should not. It's not reasonable for the *operating system* to know about every damned protocol that someone decides would be a just peachy way to access a file. Hell, it's not even practical. The idea of universal abstraction just does not work. If you think otherwise, I suggest you start coding and stop bothering the rest of us until you've made it work. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Sansonetti Laurent wrote: Anyway, the point is that a file that I can access should be a file I can access via VI or MORE or EMACS or GREP or any other tool without having those tools each having FTP and HTTP and SSH support built in to them. The OS should handle it. Yes, this should be nice. There's a similar project for Linux here: http://ftpfs.sourceforge.net/ (FTP only). It would be amusing to port it into a KLD file. Hmmm... Looks like a good first step -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
On 04-Sep-01 Michael Sinz wrote: Sansonetti Laurent wrote: Anyway, the point is that a file that I can access should be a file I can access via VI or MORE or EMACS or GREP or any other tool without having those tools each having FTP and HTTP and SSH support built in to them. The OS should handle it. Yes, this should be nice. There's a similar project for Linux here: http://ftpfs.sourceforge.net/ (FTP only). It would be amusing to port it into a KLD file. Hmmm... Looks like a good first step You may also wish to take a look at wwfs: http://www.wide.ad.jp/software/README.wwfs-109.5.html -- E-Mail: Kenneth P. Stox [EMAIL PROTECTED] Date: 04-Sep-01 Time: 09:57:36 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Charlie Root wrote: What I was trying to say is that there is no reason that I should care if the file is local or not. You do need to know if the file is local or not. You need to know for security. You need to know because files behave differently on different machines. You need to know because file structures don't map from one machine to another. You need to know because differing protocols allow you do to very different things to files. You need to know because performance varies dramatically depending on where the file is located. Ok - so my server here has files that various platforms access via NFS. The fact that everything accesses the files via NFS does not reduce or change the fact that the endian nature of the platform or the word size of the platform need to be either understood or that the file format be strictly structured so as to no matter. And if you think that each application needs to know about the different semantics of the file storage system, why is NFS just like FFS just like UFS just like FAT16 just like... Each has different limits and behaviors. NFS is very stateless. Local file systems are much more stateful. FAT has file name restrictions (pre-VFAT it was 8.3 with upper case only, for example) ISO9660 has depth limits and version numbers, VMS has version numbers and different character exclusions, etc. Some of these limits are annoying and, in some cases, incompatible with the work you may wish to do. However, most of these are limits that are also limits on other file systems (albeit different - 32 character names or 255 character names, for example, but still a name length limit) Performance differences are vast, even with local files. Have you written to a floppy lately. Almost all my network connected disks are *much* faster. How about that slow MO drive? Or that ultra-fast SCSI RAID pack? At some point the performance issues are just if you use X it will not perform like Y and not a this program can't use X because we feel it does not perform well enough and thus we did not code for it. (cp, mv, etc, all work with floppy disks and other slow media...) Just as the OS support having multiple storage devices and media and the software does not need to know if the file is on a SCSI or IDE disk or if it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if it is local or on the machine beside it or on the machine on the other side of the world? The OS support of multiple device types exists because it is possible and reasonable to abstract each of those device types into a single virtual type. When this isn't possible or reasonable, it's not only difficult but *wrong* to abstract. There are way too many things you can do with a local file that you can't do with a remote file to allow this abstraction. I never said this was trivial. We (which includes me) tried to start such a project at Amiga (Commodore) - It was well before HTTP was so popular. The goal was to hide the specifics and provide a single operation. FTP support was via a local cache while the file was open and if you did a write, it would write back the file at close time. This is due to limits in the ftp protocol, but it did not change the behavior to the application. The fact that writes were not instant to the FTP server was just one of the differences between it and other file systems. NFS had other limits. Our own network filesystem had yet other design goals and thus different limits/behaviors. The hard part we faced was the fact that the computers were much less powerful than today (slower/less RAM/ etc) and that Amiga(Commodore) was not very focused on networking (or anything else other than loosing money :-) Anyway, the point is that a file that I can access should be a file I can access via VI or MORE or EMACS or GREP or any other tool without having those tools each having FTP and HTTP and SSH support built in to them. The OS should handle it. No it should not. It's not reasonable for the *operating system* to know about every damned protocol that someone decides would be a just peachy way to access a file. Hell, it's not even practical. Not every protocol - or maybe every protocol supported by people who make the protocol filters. This is where external (to the kernel) protocol filters fit in well. But lets not go there (now). All of this started with the quest for URIs being useable everywhere. That is a nice starting point for an idea. Now, if I gave you foobar://xx/yy you might not know what to do with the foobar protocol from the URI. That would be an error, much like but not exactly like, file not found. (It would be unknown protocol as a subset of file not found, much like when you use /var/lof/messages when you were going to use /var/log/messages) The idea of universal abstraction just does not work. If you think otherwise, I suggest you start coding and stop bothering the rest of us until you've
KLD subsystem improvement
Hello, I'm going to implement a small improvement to a KLD system. I want linker file not to be loaded at all when all modules inside it fail to load for some reasons. I think that would be logical behaviour. Does anyone think that such change would break something ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
All of this started with the quest for URIs being useable everywhere. It's a stupid quest, for reasons others have pointed out. When this isn't possible or reasonable, it's not only difficult but *wrong* to abstract. I never said this was trivial. We (which includes me) tried to start such a project at Amiga (Commodore) - It was well before HTTP was so popular. The goal was to hide the specifics and provide a single operation. FTP support was via a local cache while the file was open and if you did a write, it would write back the file at close time. See above. There's a reason AFS hasn't replaced NFS. I was not asking for a magic bullet. (Well, not this time :-) I was asking that the OS support reading and/or writing of data (whatever that may be) to a file/filehandle that was created via a standard system call. Pipes, named or otherwise. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
What strikes me in this thread is that a lot of people are stupid and lazy and want FreeBSD's kernel (or libc) to do stupid things with URLs the same way you can throw a URL anywhere in Windows and have it mean something. Here's some news for you: It shouldn't, and probably won't, happen. If you really want something that insane and obscene and that much of a bastardisation of EVERYTHING networking-related, check in with the BASH people and do it on the shell level. If you're really lazy and want to be able to do: telnet smtp://localhost I suggest you look into this relatively new invention called '/etc/services' and read some manual pages. You'll find you can do something quite similar, and much saner. /joseph To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
4.4-RC3 scontrib and other files problem ?
Tried to install complete source tree via sysinstall and it always fails on scontrib with unexpected EOF. And it seems several of the chunks are not the usual 240640 bytes in size. Checked several of the FTP servers: -r--r--r-- 1 1006 1006 231335 Sep 2 04:23 sbin.ab -r--r--r-- 1 1006 1006 3763 Sep 1 18:55 scontrib.cq -r--r--r-- 1 1006 100663151 Sep 1 18:55 scontrib.cu -r--r--r-- 1 1006 1006 7233 Sep 1 18:55 scontrib.cz -r--r--r-- 1 1006 1006 2145984 Sep 1 18:55 scontrib.eh -r--r--r-- 1 1006 100666801 Sep 1 18:55 scontrib.en -r--r--r-- 1 1006 1006 1096775 Sep 1 18:55 scontrib.ex -r--r--r-- 1 1006 1006 6778448 Sep 1 18:55 sgames.ag -r--r--r-- 1 1006 1006 7834 Sep 1 18:55 slib.bb All the ones which are shorter then 240640 bytes are no the last file in their sequences. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
In message [EMAIL PROTECTED], Maxim Sobolev writes:
In message [EMAIL PROTECTED], Brent Verner writes:
I've done a /cursory/ look over how this v_tag is used. I'm not sure
this is a simple/clean as you propose, since this is used in the
IS_LOCKING_VFS macro, as well as in union_subr.c...
Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
The places which inspect v_tag will have to be changed to use
strcmp() then...
I think that we can add a new vnode flag, say VCANLOCK, so that each
particular VFS can set it if it supports locking, which should allow
to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
produce a patch if it sounds reasonably.
Yeah, I think that makes a lot of sense.
See attached. Please let me know if it is OK for you.
-Maxim
Index: isofs/cd9660/cd9660_vfsops.c
===
RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v
retrieving revision 1.91
diff -d -u -r1.91 cd9660_vfsops.c
--- isofs/cd9660/cd9660_vfsops.c2001/05/16 18:04:30 1.91
+++ isofs/cd9660/cd9660_vfsops.c2001/09/04 15:20:46
@@ -697,6 +697,7 @@
}
MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE,
M_WAITOK | M_ZERO);
+ vp-v_flag |= VLOCKABLE;
lockinit(vp-v_lock, PINOD, isonode, 0, 0);
/*
* ISOFS uses stdlock and can share lock structure
Index: ufs/ffs/ffs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.157
diff -d -u -r1.157 ffs_vfsops.c
--- ufs/ffs/ffs_vfsops.c2001/06/28 22:21:27 1.157
+++ ufs/ffs/ffs_vfsops.c2001/09/04 15:21:25
@@ -1172,6 +1172,7 @@
return (error);
}
bzero((caddr_t)ip, sizeof(struct inode));
+ vp-v_flag |= VLOCKABLE;
/*
* FFS supports lock sharing in the stack of vnodes
*/
Index: ufs/ifs/ifs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v
retrieving revision 1.6
diff -d -u -r1.6 ifs_vfsops.c
--- ufs/ifs/ifs_vfsops.c2001/04/25 07:07:51 1.6
+++ ufs/ifs/ifs_vfsops.c2001/09/04 15:21:25
@@ -217,6 +217,7 @@
return (error);
}
bzero((caddr_t)ip, sizeof(struct inode));
+ vp-v_flag |= VLOCKABLE;
/*
* IFS supports lock sharing in the stack of vnodes
*/
Index: nfs/nfs_node.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v
retrieving revision 1.49
diff -d -u -r1.49 nfs_node.c
--- nfs/nfs_node.c 2001/05/01 08:13:14 1.49
+++ nfs/nfs_node.c 2001/09/04 15:21:25
@@ -232,6 +232,7 @@
}
vp = nvp;
bzero((caddr_t)np, sizeof *np);
+ vp-v_flag |= VLOCKABLE;
vp-v_data = np;
np-n_vnode = vp;
/*
Index: sys/vnode.h
===
RCS file: /home/ncvs/src/sys/sys/vnode.h,v
retrieving revision 1.154
diff -d -u -r1.154 vnode.h
--- sys/vnode.h 2001/08/27 06:09:55 1.154
+++ sys/vnode.h 2001/09/04 15:21:25
@@ -175,6 +175,7 @@
/* open for business 0x10 */
#defineVONWORKLST 0x20 /* On syncer work-list */
#defineVMOUNT 0x40 /* Mount in progress */
+#define VLOCKABLE 0x60 /* vnode supports locking */
/*
* Vnode attributes. A field value of VNOVAL represents a field whose value
@@ -433,12 +434,7 @@
/*
* [dfr] Kludge until I get around to fixing all the vfs locking.
*/
-#define IS_LOCKING_VFS(vp) ((vp)-v_tag == VT_UFS \
-|| (vp)-v_tag == VT_NFS \
-|| (vp)-v_tag == VT_LFS \
-|| (vp)-v_tag == VT_ISOFS \
-|| (vp)-v_tag == VT_MSDOSFS \
-|| (vp)-v_tag == VT_DEVFS)
+#define IS_LOCKING_VFS(vp) ((vp)-v_flag VLOCKABLE)
#define ASSERT_VOP_LOCKED(vp, str) \
do { \
Index: fs/devfs/devfs_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v
retrieving revision 1.27
diff -d -u -r1.27 devfs_vnops.c
--- fs/devfs/devfs_vnops.c 2001/08/14 06:42:32 1.27
+++ fs/devfs/devfs_vnops.c 2001/09/04 15:21:25
@@ -151,6 +151,7 @@
} else {
vp-v_type = VBAD;
}
+ vp-v_flag |= VLOCKABLE;
vp-v_data = de;
de-de_vnode = vp;
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p);
Index: fs/msdosfs/msdosfs_denode.c
===
RCS
Re: Junior Kernel Hacker task: improve vnode-v_tag
Hi Maxim, Perhaps you meant: diff -d -u -r1.154 vnode.h --- sys/vnode.h 2001/08/27 06:09:55 1.154 +++ sys/vnode.h 2001/09/04 15:21:25 @@ -175,6 +175,7 @@ /* open for business 0x10 */ #defineVONWORKLST 0x20 /* On syncer work-list */ #defineVMOUNT 0x40 /* Mount in progress */ +#define VLOCKABLE 0x60 /* vnode supports locking */ ...should be +#define VLOCKABLE 0x80 /* vnode supports locking */ ? Regards, Konstantin. Maxim Sobolev wrote: In message [EMAIL PROTECTED], Maxim Sobolev writes: In message [EMAIL PROTECTED], Brent Verner writes: I've done a /cursory/ look over how this v_tag is used. I'm not sure this is a simple/clean as you propose, since this is used in the IS_LOCKING_VFS macro, as well as in union_subr.c... Well, that is just too bad, because IS_LOCKING_VFS is wrong then. The places which inspect v_tag will have to be changed to use strcmp() then... I think that we can add a new vnode flag, say VCANLOCK, so that each particular VFS can set it if it supports locking, which should allow to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can produce a patch if it sounds reasonably. Yeah, I think that makes a lot of sense. See attached. Please let me know if it is OK for you. -Maxim -- Name: p p Type: Plain Text (text/plain) Encoding: 7bit Description: ASCII C program text -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.netUnited Kingdom To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
apart from the numerical value, yes, looks good.
Poul-Henning
In message [EMAIL PROTECTED], Maxim Sobolev writes:
--%--multipart-mixed-boundary-1.97537.999617732--%
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
In message [EMAIL PROTECTED], Maxim Sobolev writes:
In message [EMAIL PROTECTED], Brent Verner writes:
I've done a /cursory/ look over how this v_tag is used. I'm not sure
this is a simple/clean as you propose, since this is used in the
IS_LOCKING_VFS macro, as well as in union_subr.c...
Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
The places which inspect v_tag will have to be changed to use
strcmp() then...
I think that we can add a new vnode flag, say VCANLOCK, so that each
particular VFS can set it if it supports locking, which should allow
to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
produce a patch if it sounds reasonably.
Yeah, I think that makes a lot of sense.
See attached. Please let me know if it is OK for you.
-Maxim
--%--multipart-mixed-boundary-1.97537.999617732--%
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Description: ASCII C program text
Content-Disposition: attachment; filename=p
Index: isofs/cd9660/cd9660_vfsops.c
===
RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v
retrieving revision 1.91
diff -d -u -r1.91 cd9660_vfsops.c
--- isofs/cd9660/cd9660_vfsops.c 2001/05/16 18:04:30 1.91
+++ isofs/cd9660/cd9660_vfsops.c 2001/09/04 15:20:46
@@ -697,6 +697,7 @@
}
MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE,
M_WAITOK | M_ZERO);
+ vp-v_flag |= VLOCKABLE;
lockinit(vp-v_lock, PINOD, isonode, 0, 0);
/*
* ISOFS uses stdlock and can share lock structure
Index: ufs/ffs/ffs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.157
diff -d -u -r1.157 ffs_vfsops.c
--- ufs/ffs/ffs_vfsops.c 2001/06/28 22:21:27 1.157
+++ ufs/ffs/ffs_vfsops.c 2001/09/04 15:21:25
@@ -1172,6 +1172,7 @@
return (error);
}
bzero((caddr_t)ip, sizeof(struct inode));
+ vp-v_flag |= VLOCKABLE;
/*
* FFS supports lock sharing in the stack of vnodes
*/
Index: ufs/ifs/ifs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v
retrieving revision 1.6
diff -d -u -r1.6 ifs_vfsops.c
--- ufs/ifs/ifs_vfsops.c 2001/04/25 07:07:51 1.6
+++ ufs/ifs/ifs_vfsops.c 2001/09/04 15:21:25
@@ -217,6 +217,7 @@
return (error);
}
bzero((caddr_t)ip, sizeof(struct inode));
+ vp-v_flag |= VLOCKABLE;
/*
* IFS supports lock sharing in the stack of vnodes
*/
Index: nfs/nfs_node.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v
retrieving revision 1.49
diff -d -u -r1.49 nfs_node.c
--- nfs/nfs_node.c 2001/05/01 08:13:14 1.49
+++ nfs/nfs_node.c 2001/09/04 15:21:25
@@ -232,6 +232,7 @@
}
vp = nvp;
bzero((caddr_t)np, sizeof *np);
+ vp-v_flag |= VLOCKABLE;
vp-v_data = np;
np-n_vnode = vp;
/*
Index: sys/vnode.h
===
RCS file: /home/ncvs/src/sys/sys/vnode.h,v
retrieving revision 1.154
diff -d -u -r1.154 vnode.h
--- sys/vnode.h2001/08/27 06:09:55 1.154
+++ sys/vnode.h2001/09/04 15:21:25
@@ -175,6 +175,7 @@
/* open for business 0x10 */
#define VONWORKLST 0x20 /* On syncer work-list */
#define VMOUNT 0x40 /* Mount in progress */
+#define VLOCKABLE 0x60 /* vnode supports locking */
/*
* Vnode attributes. A field value of VNOVAL represents a field whose value
@@ -433,12 +434,7 @@
/*
* [dfr] Kludge until I get around to fixing all the vfs locking.
*/
-#define IS_LOCKING_VFS(vp)((vp)-v_tag == VT_UFS \
- || (vp)-v_tag == VT_NFS \
- || (vp)-v_tag == VT_LFS \
- || (vp)-v_tag == VT_ISOFS \
- || (vp)-v_tag == VT_MSDOSFS \
- || (vp)-v_tag == VT_DEVFS)
+#define IS_LOCKING_VFS(vp)((vp)-v_flag VLOCKABLE)
#define ASSERT_VOP_LOCKED(vp, str)\
do { \
Index: fs/devfs/devfs_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v
retrieving revision 1.27
diff -d -u -r1.27 devfs_vnops.c
---
Re: Junior Kernel Hacker task: improve vnode-v_tag
In message [EMAIL PROTECTED], Brent Verner writes: On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote: | | Assignment: | | The v_tag element in struct vnode is a debugging aid, but unfortunately | it is implemented in a way which means that adding a filesystem means | modifying the definition in sys/vnode.h. | | Convert the v_tag to an const char * and have the filesystems put | their name in there instead. | | The v_tag has been abused a few places, easily recognizable by the fact | that the kernel should never inspect the value of v_tag. | These places should be easily changeable to use the new representation. | Please mark them with a big fat /*XXX: ABUSE OF v_tag */ comment. #include newbie_kernel_hacker_warning.h I've done a /cursory/ look over how this v_tag is used. I'm not sure this is a simple/clean as you propose, since this is used in the IS_LOCKING_VFS macro, as well as in union_subr.c... Well, that is just too bad, because IS_LOCKING_VFS is wrong then. The places which inspect v_tag will have to be changed to use strcmp() then... I think that we can add a new vnode flag, say VCANLOCK, so that each particular VFS can set it if it supports locking, which should allow to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can produce a patch if it sounds reasonably. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
In message [EMAIL PROTECTED], Maxim Sobolev writes: In message [EMAIL PROTECTED], Brent Verner writes: On 04 Sep 2001 at 10:36 (+0200), Poul-Henning Kamp wrote: | | Assignment: | | The v_tag element in struct vnode is a debugging aid, but unfortunately | it is implemented in a way which means that adding a filesystem means | modifying the definition in sys/vnode.h. | | Convert the v_tag to an const char * and have the filesystems put | their name in there instead. | | The v_tag has been abused a few places, easily recognizable by the fact | that the kernel should never inspect the value of v_tag. | These places should be easily changeable to use the new representation. | Please mark them with a big fat /*XXX: ABUSE OF v_tag */ comment. #include newbie_kernel_hacker_warning.h I've done a /cursory/ look over how this v_tag is used. I'm not sure this is a simple/clean as you propose, since this is used in the IS_LOCKING_VFS macro, as well as in union_subr.c... Well, that is just too bad, because IS_LOCKING_VFS is wrong then. The places which inspect v_tag will have to be changed to use strcmp() then... I think that we can add a new vnode flag, say VCANLOCK, so that each particular VFS can set it if it supports locking, which should allow to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can produce a patch if it sounds reasonably. Yeah, I think that makes a lot of sense. -- 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-hackers in the body of the message
Re: What is VT_TFS?
What is the file system that uses VT_TFS in vnode.h? Is it still available on FreeBSD? Thanks. Julian added it for TRW Financial Services; the first public reference machine for 386BSD (which later became FreeBSD and NetBSD) was ref.tfs.com. So far so good. ref died an ugly horrible death, although I think I still have lying around a 4mm backup tape of what was left of it. TRW supported a lot of the early 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw in and had us change the version number from 0.1 to 1.0 to make it a bit easier to sell. *Huh* That's revisionist history if I've ever heard it. We did a 1.0 release for FreeBSD because we wanted to differentiate ourselves from 386BSD (lot of bad blood there with the Jolitz's) and NetBSD (which had a 0.8 release at that time). Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: What is VT_TFS?
In message [EMAIL PROTECTED], Nate Williams writes: TRW supported a lot of the early 386BSD/FreeBSD effort, back before Walnut Creek CDROM threw in and had us change the version number from 0.1 to 1.0 to make it a bit easier to sell. *Huh* That's revisionist history if I've ever heard it. We did a 1.0 release for FreeBSD because we wanted to differentiate ourselves from 386BSD (lot of bad blood there with the Jolitz's) and NetBSD (which had a 0.8 release at that time). Nate, You're replying to Terry for christs sake! What did you expect if not revisionist $anything ? Which reminds me, Adrian still oves us his story about ref :-) -- 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-hackers in the body of the message
Tagged Command Queuing support for IC-35L0?0 ?
Hi, I posted this message on -questions, and since I got no reply I've assumed that it's technical enough to post here on -hackers. Since FBSD 4.3-RELEASE, tagged command queuing is supported for IBM DTLA and DPTA IDE drives. However, the newer Deskstar GXP drives also support TCQ according to IBM's website? Can these newer drives, based on the IC-35L0?0-chipset, also be used with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the drive has 20, 40 or 60 GB capacity). Thanks in advance, Niek Bergboer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: What is VT_TFS?
On Tue, 4 Sep 2001, Poul-Henning Kamp wrote: Which reminds me, Adrian still oves us his story about ref :-) Yeah, the REAL one... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tagged Command Queuing support for IC-35L0?0 ?
Niek Bergboer wrote:
Hi,
I posted this message on -questions, and since I got no reply I've
assumed that it's technical enough to post here on -hackers.
Since FBSD 4.3-RELEASE, tagged command queuing is supported for IBM
DTLA and DPTA IDE drives. However, the newer Deskstar GXP drives
also support TCQ according to IBM's website?
Can these newer drives, based on the IC-35L0?0-chipset, also be used
with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the
drive has 20, 40 or 60 GB capacity).
I think so:
ad0: 58644MB IC35L060AVER07-0 [119150/16/63] at ata0-master tagged
UDMA33
I had to manually add IC35L060AVER07-0 to ata-disk.c (around line 832)
to get FreeBSD to use it though.
...
ad_tagsupported(struct ad_softc *adp)
{
const char *drives[] = {IBM-DPTA, IBM-DTLA, IC35L060AVER07-0,
NULL};
...
This was a month or so though, so someone might have done the right
thing
and figured out how to parse those new IBM product strings to determine
if the drive supports CTQ or not.
--
\ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED]
|\/ | ||/ _| Network and Distributed Systems Engineer
_| _|___| _| _|_\___| Office: 703-883-7755
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
NAME amd - automatically mount file systems ... DESCRIPTION Amd is a daemon that automatically mounts filesystems whenever a file or directory within that filesystem is accessed. Filesystems are automati- cally unmounted when they appear to be quiescent. Ahh, but that assumes that your AMD configuration has all systems and mount points enumerated in it. Let me see - I think that 30gig drive may be big enough for that file :-) No. Set amd_enable to YES in /etc/rc.conf and the default configuration will let you do a cd /net/nfs_servername.someplace to view all NFS exported filesystems on nfs_servername.someplace. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: signal handling descrpancy (FreeBSD oaf fix/Evolution)
On Sun, Sep 02, 2001 at 09:55:03AM -0700, David O'Brien wrote: The PIM Evolution, http://www.ximian.com/products/ximian_evolution/, does not run on FreeBSD. The authors have made a change so that it will. However, we would like to know if FreeBSD is the odd-man-out, or if the authors were lucky Evolution ran on Solaris and Linux. I think this is the change which we had a patch for recently. It was committed to -current and -stable recently. Unfortunately there was a small problem with the implimentation and had to be backed out. I think either Matt or Ian or both had fixes for the problems, but they haven't been recommitted yet. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Question about VLAN dot1q tagging in FreeBSD
Got a question for the people who worked on the support. All my experience is under 4.3-Release/-Stable/4.4-RC3. A while back when I wanted to use dot1q tagging, it seems to work fine with the expection that I wasn't able to get VLAN 1 (default VLAN) to work. Last night I setup dot1q tagging again on another machine and had the same problem. Looking into packets sent down the trunk, I saw that VLAN 1 wasn't tagged (I assume the dot1q spec tells so that VLAN 1 packets aren't tagged, while other VLANs are). If this is right, I think we should mention this in the man page. Here is a copy of the current man page of ifconfig in regards to VLAN: vlan vlan_tag If the interface is a vlan pseudo interface, set the vlan tag value to vlan_tag. This value is a 16-bit number which is used to create an 802.1Q vlan header for packets sent from the vlan interface. Note that vlan and vlandev must both be set at the same time. vlandev iface If the interface is a vlan pseudo device, associate physical interface iface with it. Packets transmitted through the vlan interface will be diverted to the specified physical interface iface with 802.1Q vlan encapsulation. Packets with 802.1Q encap- sulation received by the parent interface with the correct vlan tag will be diverted to the associated vlan pseudo-interface. The vlan interface is assigned a copy of the parent interface's flags and the parent's ethernet address. The vlandev and vlan must both be set at the same time. If the vlan interface already has a physical interface associated with it, this command will fail. To change the association to another physical interface, the existing association must be cleared first. Note: if the link0 flag is set on the vlan interface, the vlan pseudo interface's behavior changes: the link0 tells the vlan interface that the parent interface supports insertion and extraction of vlan tags on its own (usually in firmware) and that it should pass packets to and from the parent unaltered. -vlandev iface If the driver is a vlan pseudo device, disassociate the physical interface iface from it. This breaks the link between the vlan interface and its parent, clears its vlan tag, flags and its link address and shuts the interface down. My current config in the case I setup last night looks like this from /etc/rc.conf: network_interfaces=fxp0 vlan2 lo0 ifconfig_fxp0=inet 192.168.0.250 netmask 255.255.255.0 media 100basetx mediaopt full-duplex ifconfig_vlan2=inet 64.81.63.130 netmask 255.255.255.224 vlan 2 vlandev fxp0 192.168.0.250 is my private LAN which is VLAN 1 on my switches. VLAN 2 and 3 are my external networks (DSL/Cable Modem). My suggestion is to add to ifconfig man page something like this under vlan vlan_tag: Note: VLAN 1 is not tagged and should be put directly on the physical interface. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Question about VLAN dot1q tagging in FreeBSD
On Tue, Sep 04, 2001 at 02:19:06PM -0700, Ulf Zimmermann wrote: Last night I setup dot1q tagging again on another machine and had the same problem. Looking into packets sent down the trunk, I saw that VLAN 1 wasn't tagged (I assume the dot1q spec tells so that VLAN 1 packets aren't tagged, while other VLANs are). If this is right, I think we should mention this in the man page. Here is a copy of the current man page of ifconfig in regards to VLAN: It is slightly more complicated. 802.1q allows a single, untagged vlan to operate across a link for compatability reasons, and calls it the 'default' VLAN. There is no requirement that it be VLAN 1. That is, you could set the default vlan to be 10 on both sides, and tag all the rest (including 1). You could also set vlan 1 on one side, and vlan 10 on the other, and they would be bridged together. Cisco devices warn when you do this (via CDP, it must be enabled). Convention seems to be that vlan 1 is the 'default vlan' on almost all devices. Having better notes in a man page would be good. -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Question about VLAN dot1q tagging in FreeBSD
On Tue, Sep 04, 2001 at 05:24:50PM -0400, Leo Bicknell wrote: On Tue, Sep 04, 2001 at 02:19:06PM -0700, Ulf Zimmermann wrote: Last night I setup dot1q tagging again on another machine and had the same problem. Looking into packets sent down the trunk, I saw that VLAN 1 wasn't tagged (I assume the dot1q spec tells so that VLAN 1 packets aren't tagged, while other VLANs are). If this is right, I think we should mention this in the man page. Here is a copy of the current man page of ifconfig in regards to VLAN: It is slightly more complicated. 802.1q allows a single, untagged vlan to operate across a link for compatability reasons, and calls it the 'default' VLAN. There is no requirement that it be VLAN 1. That is, you could set the default vlan to be 10 on both sides, and tag all the rest (including 1). You could also set vlan 1 on one side, and vlan 10 on the other, and they would be bridged together. Cisco devices warn when you do this (via CDP, it must be enabled). All the documentation I have read lately seemed to indicated that VLAN 1 is the one to be present, but I haven't read the dot1q spec (time to do that (: ). Convention seems to be that vlan 1 is the 'default vlan' on almost all devices. Having better notes in a man page would be good. We should at least put a note into the man about it, different wording when what I had posted. I haven't checked the handbook lately, but every time I mention dot1q tagging and FreeBSD, I seem to find someone who says the documentation about it is very sparse. We might want to review that too. I personal use it for lab setups I have done at home (been trying to CCIE, but right now I am having a grudge against Cisco and their supposely high quality about the tests (Lab protoctor showed up late, didn't give the lost time at the end, errors in the documentation of the lab, no reply from the CCIE program so far)). -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
If you're really lazy and want to be able to do: telnet smtp://localhost I suggest you look into this relatively new invention called '/etc/services' and read some manual pages. You'll find you can do something quite similar, and much saner. I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost should do something useful. Nor do I consider his idea lazy. I do think that he was suggesting, and I concur, that there's no logical reason that networked file access should be treated differently by user applications than local file access. I strongly suggest you read his post again, and think about how nice it is for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS, etc and have user-level programs access their data in exactly the same manner. This is not an LSD-induced 'turn freebsd into windows' idea, it's a very simple extension of ideas that FreeBSD already has in place. Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Kevin Way [EMAIL PROTECTED] types: If you're really lazy and want to be able to do: telnet smtp://localhost I suggest you look into this relatively new invention called '/etc/services' and read some manual pages. You'll find you can do something quite similar, and much saner. I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost should do something useful. Nor do I consider his idea lazy. I do think that he was suggesting, and I concur, that there's no logical reason that networked file access should be treated differently by user applications than local file access. I would concur with that, so long as you remember that local file access involves someone making usually-privileged system calls to arrange to map those remote name spaces into the local name space. That is different from making URLs pervasive. For one thing, it doesn't muck with the local name space. If URL's are pervasive and I issue the comand vi mailto:[EMAIL PROTECTED];, am I going to edit a file in the local directory called mailto:[EMAIL PROTECTED], or am I going to send a mail message to [EMAIL PROTECTED]? For another, it provides a place to hang information that's global about that mapping - for instance, providing uids and permission bits to handed back from file systems that don't have them. I strongly suggest you read his post again, and think about how nice it is for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS, etc and have user-level programs access their data in exactly the same manner. Those are all file systems, and operations on the things on them all have pretty much the same semantics. This isn't true for URLs in general. It's true for some subset of the available schemes, and I don't think anyone would object to file system modules for ftp or http. You can even do this in userland with an nfs server API if you want it to be portable. However, not all URI schemes have that property. For instance, Mike refers to emacs having transparent FTP support. It's not really transparent, as opening a local file never asks me for a password! If the ftp server is mounted, then you can provide authentication information as options to the mount. You can even deal with FTP servers that want an ACCT command, which doesn't have a place in the RFC 1738 ftp scheme. I don't know of any application that handles local files that responds to any open error by prompting for a password. If open can now return an HTTP 401 error, every application is going to need to be able to deal with that in some sane way. Either that, or users are going to have to know the proper syntax for usernames and passwords in every URL scheme they deal with - and start putting passwords on command lines, and other things that give security officers nightmares. This is not an LSD-induced 'turn freebsd into windows' idea, it's a very simple extension of ideas that FreeBSD already has in place. Conceptually, it may be very simple. In practice, it's very, very messy. The correct thing to do with a URL is going to depend on the application that's doing it, what the application is doing, and the scheme for the URL. The application is really the only thing that can figure all that out. In the simplest possible example, cat can just treat appropriate URLs like files and read from them. vi - or something that vi is talking to - needs to be taught how to deal with streaming data in some way. Sockets are similar in many respects. In a lot of ways, sockets look like file descriptors with some extra functions that can be applied to them. In many cases, all you do with a socket once you've got it is standard file descriptor calls. However, the kernel doesn't let you just open a socket. Yes, there are file systems that let you treat a subset of the possible sockets and socket operations that way. But to take full advantage of them, you have to use a different API. In summary, each command needs to decide - possibly on a case-by-case basis whether or not the string it's got is a URL or a file name. It needs to decide how the operation it's been asked to be performed can be performed on the object that URL represents, and if so how it should be mapped. If it's a URL, the application may well have to deal with events that don't happen with local files. All of which is why I think we're already moving in the right direction. We've got a library routine that you can hand a URL to, and it hands back FILE *. We've also got routines that will parse the URL so you can manipulate it, for instance plugging in a new password and user name that the application got from the user in a manner appropriate for that application. For some reason, this all brings to mind the request to make open act like the Perl open. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe:
Re: Flow cache on FreeBSD?
Hello, | Yes. Please go and find the NeTraMet package on the web - it should NeTraMet is in the ports so you don't have to search it on the web: /usr/ports/net/NeTraMet/ -- Mit freundlichen Gruessen, Marco Wertejuk - mwcis.com Computer/Internet/Security-Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Performance?
Leo Bicknell wrote: On Mon, Sep 03, 2001 at 06:01:04PM -0600, Ronald G Minnich wrote: you do know that API just layed off (almost) all their alpha people, right? alpha is dead. Thank compaq any time. ron (who owns 112 Compaq Alpha boxes, and 16 API CS20s) No I didn't. That's really sad. I wonder if the impending Hewlett-Compaqard merger will hasten the Alpha into its grave. The King is Dead, Long Live the King! -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Flow cache on FreeBSD?
Is there a way to provide functionality similar to ip flow cache stats on a FreeBSD router? Let me clarify, I am talking about being able to easily see groupings of traffic go through a FreeBSD box. So if a downstream customer is being attacked, a simple table in realtime [or near real-time] will show the attack characteristics [ip ranges, packet types, general number of packets, etc].? Thanks, Deepak Jain AiNET To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Flow cache on FreeBSD?
Deepak Jain wrote: Is there a way to provide functionality similar to ip flow cache stats on a FreeBSD router? Let me clarify, I am talking about being able to easily see groupings of traffic go through a FreeBSD box. So if a downstream customer is being attacked, a simple table in realtime [or near real-time] will show the attack characteristics [ip ranges, packet types, general number of packets, etc].? Yes. Please go and find the NeTraMet package on the web - it should compile cleanly on FreeBSD (if not the latest versions, then surely some older - I used them some time ago). It's very configurable, and comes with a lot of examples (among others, and XWindow application to watch the flows in real-time). -- Andrzej // // Andrzej Bialecki [EMAIL PROTECTED], Chief System Architect // WebGiro AB, Sweden (http://www.webgiro.com) // // [EMAIL PROTECTED] FreeBSD developer (http://www.freebsd.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
On Tue, 4 Sep 2001, Maxim Sobolev wrote: The places which inspect v_tag will have to be changed to use strcmp() then... I think that we can add a new vnode flag, say VCANLOCK, so that each particular VFS can set it if it supports locking, which should allow to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can produce a patch if it sounds reasonably. I'm not sure if this a right thing to do. Under SMPng each filesystem is ought to implement correct vnode locking, i.e. vop_nolock() and friends shouldn't exist. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
On Tue, 4 Sep 2001, Maxim Sobolev wrote: [neither Maxim Sobolev nor Brent Verner wrote] In message [EMAIL PROTECTED], Brent Verner writes: #include newbie_kernel_hacker_warning.h I've done a /cursory/ look over how this v_tag is used. I'm not sure this is a simple/clean as you propose, since this is used in the IS_LOCKING_VFS macro, as well as in union_subr.c... Well, that is just too bad, because IS_LOCKING_VFS is wrong then. The places which inspect v_tag will have to be changed to use strcmp() then... I think that we can add a new vnode flag, say VCANLOCK, so that each particular VFS can set it if it supports locking, which should allow to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can produce a patch if it sounds reasonably. Since IS_LOCKING_VFS() is a temporary kludge, the correct fix is to remove it (after fixing whatever it was for), not to add more cruft. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
apart from the numerical value, yes, looks good.
Ok, please find the final patch attached. Dare I say that it looks really
ugly?
I'm looking forward for your comments.
-Maxim
Poul-Henning
In message [EMAIL PROTECTED], Maxim Sobolev writes:
--%--multipart-mixed-boundary-1.97537.999617732--%
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
In message [EMAIL PROTECTED], Maxim Sobolev writes:
In message [EMAIL PROTECTED], Brent Verner writes:
I've done a /cursory/ look over how this v_tag is used. I'm not sure
this is a simple/clean as you propose, since this is used in the
IS_LOCKING_VFS macro, as well as in union_subr.c...
Well, that is just too bad, because IS_LOCKING_VFS is wrong then.
The places which inspect v_tag will have to be changed to use
strcmp() then...
I think that we can add a new vnode flag, say VCANLOCK, so that each
particular VFS can set it if it supports locking, which should allow
to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can
produce a patch if it sounds reasonably.
Yeah, I think that makes a lot of sense.
See attached. Please let me know if it is OK for you.
-Maxim
--%--multipart-mixed-boundary-1.97537.999617732--%
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Description: ASCII C program text
Content-Disposition: attachment; filename=p
Index: isofs/cd9660/cd9660_vfsops.c
===
RCS file: /home/ncvs/src/sys/isofs/cd9660/cd9660_vfsops.c,v
retrieving revision 1.91
diff -d -u -r1.91 cd9660_vfsops.c
--- isofs/cd9660/cd9660_vfsops.c 2001/05/16 18:04:30 1.91
+++ isofs/cd9660/cd9660_vfsops.c 2001/09/04 15:20:46
@@ -697,6 +697,7 @@
}
MALLOC(ip, struct iso_node *, sizeof(struct iso_node), M_ISOFSNODE,
M_WAITOK | M_ZERO);
+vp-v_flag |= VLOCKABLE;
lockinit(vp-v_lock, PINOD, isonode, 0, 0);
/*
* ISOFS uses stdlock and can share lock structure
Index: ufs/ffs/ffs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.157
diff -d -u -r1.157 ffs_vfsops.c
--- ufs/ffs/ffs_vfsops.c 2001/06/28 22:21:27 1.157
+++ ufs/ffs/ffs_vfsops.c 2001/09/04 15:21:25
@@ -1172,6 +1172,7 @@
return (error);
}
bzero((caddr_t)ip, sizeof(struct inode));
+vp-v_flag |= VLOCKABLE;
/*
* FFS supports lock sharing in the stack of vnodes
*/
Index: ufs/ifs/ifs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ifs/ifs_vfsops.c,v
retrieving revision 1.6
diff -d -u -r1.6 ifs_vfsops.c
--- ufs/ifs/ifs_vfsops.c 2001/04/25 07:07:51 1.6
+++ ufs/ifs/ifs_vfsops.c 2001/09/04 15:21:25
@@ -217,6 +217,7 @@
return (error);
}
bzero((caddr_t)ip, sizeof(struct inode));
+vp-v_flag |= VLOCKABLE;
/*
* IFS supports lock sharing in the stack of vnodes
*/
Index: nfs/nfs_node.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_node.c,v
retrieving revision 1.49
diff -d -u -r1.49 nfs_node.c
--- nfs/nfs_node.c 2001/05/01 08:13:14 1.49
+++ nfs/nfs_node.c 2001/09/04 15:21:25
@@ -232,6 +232,7 @@
}
vp = nvp;
bzero((caddr_t)np, sizeof *np);
+vp-v_flag |= VLOCKABLE;
vp-v_data = np;
np-n_vnode = vp;
/*
Index: sys/vnode.h
===
RCS file: /home/ncvs/src/sys/sys/vnode.h,v
retrieving revision 1.154
diff -d -u -r1.154 vnode.h
--- sys/vnode.h 2001/08/27 06:09:55 1.154
+++ sys/vnode.h 2001/09/04 15:21:25
@@ -175,6 +175,7 @@
/* open for business0x10 */
#define VONWORKLST 0x20 /* On syncer work-list */
#define VMOUNT 0x40 /* Mount in progress */
+#define VLOCKABLE 0x60 /* vnode supports locking */
/*
* Vnode attributes. A field value of VNOVAL represents a field whose value
@@ -433,12 +434,7 @@
/*
* [dfr] Kludge until I get around to fixing all the vfs locking.
*/
-#define IS_LOCKING_VFS(vp) ((vp)-v_tag == VT_UFS \
- || (vp)-v_tag == VT_NFS \
- || (vp)-v_tag == VT_LFS \
- || (vp)-v_tag == VT_ISOFS \
- || (vp)-v_tag == VT_MSDOSFS \
- || (vp)-v_tag == VT_DEVFS)
+#define IS_LOCKING_VFS(vp) ((vp)-v_flag VLOCKABLE)
#define ASSERT_VOP_LOCKED(vp, str) \
do {\
Index: fs/devfs/devfs_vnops.c
Re: Should URL's be pervasive.
On Tue, Sep 04, 2001 at 07:08:44PM -0500, Mike Meyer wrote: Kevin Way [EMAIL PROTECTED] types: I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost should do something useful. Nor do I consider his idea lazy. I do think that he was suggesting, and I concur, that there's no logical reason that networked file access should be treated differently by user applications than local file access. I would concur with that, so long as you remember that local file access involves someone making usually-privileged system calls to arrange to map those remote name spaces into the local name space. That is different from making URLs pervasive. Agreed. You'll notice I agreed with Michael Sinz's post, not the pro-URL posts. I like the idea of being able to say... mount -t http http://www.freebsd.org/ /www/freebsd cat /www/freebsd/doc/en_US.ISO8859-1/books/faq/index.html even a simple example like 'cat http://www.freebsd.org/' seems nice, but it raises as more questions than it answers. Obviously protocols which are not file oriented won't translate effectively into filesystems. mailto is an excellent example of a scheme that doesn't translate effectively into a filesystem translation layer. I'd have no idea what to do with a mailto url, or how to reference it as a filesystem. Combine the above filesystem concept with something like amd, and many activities become extremely convenient. I strongly suggest you read his post again, and think about how nice it is for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS, etc and have user-level programs access their data in exactly the same manner. Those are all file systems, and operations on the things on them all have pretty much the same semantics. This isn't true for URLs in general. Agreed. It's true for some subset of the available schemes, and don't think anyone would object to file system modules for ftp or http. this is what the post I agred with was suggesting. this is what i believe would be a good idea. You can even do this in userland with an nfs server API if you want it to be portable. Novel idea. I'll file it into the maybe pile. I don't know of any application that handles local files that responds to any open error by prompting for a password. If open can now return an HTTP 401 error, every application is going to need to be able to deal with that in some sane way. Either that, or users are going to have to know the proper syntax for usernames and passwords in every URL scheme they deal with - and start putting passwords on command lines, and other things that give security officers nightmares. I would imagine that an http filesystem layer would return EACCES for a 401, as that would probably cause any program to return a sane error to the user. This is not an LSD-induced 'turn freebsd into windows' idea, it's a very simple extension of ideas that FreeBSD already has in place. Conceptually, it may be very simple. In practice, it's very, very messy. The correct thing to do with a URL is going to depend on the application that's doing it, what the application is doing, and the scheme for the URL. The application is really the only thing that can figure all that out. In the simplest possible example, cat can just treat appropriate URLs like files and read from them. vi - or something that vi is talking to - needs to be taught how to deal with streaming data in some way. Yes, unfortunately all ideas are just a Simple Matter of Programming... One miscommunication I should apologize for, I'm not suggesting the URLification of FreeBSD. I'm suggesting that it would be a Good Thing if files available via any common networked file transfer protocol were able to be accessed via standard system calls. In summary, each command needs to decide - possibly on a case-by-case basis whether or not the string it's got is a URL or a file name. It needs to decide how the operation it's been asked to be performed can be performed on the object that URL represents, and if so how it should be mapped. If it's a URL, the application may well have to deal with events that don't happen with local files. I really don't want all that in every command. I want it in a filesystem layer, where appropriate, as described above. Anyway, in conclusion it would seem to me that we agree, but there was a misunderstanding because I did a poor job of clipping relevant text to show what it was I was agreeing with. I apologize for the miscommunication. Kevin Way PGP signature
Re: Tagged Command Queuing support for IC-35L0?0 ?
On Tue, Sep 04, 2001 at 07:20:30PM +0200, Niek Bergboer wrote:
Can these newer drives, based on the IC-35L0?0-chipset, also be used
with TCQ enabled in FBSD? (? is 2, 4 or 6 depending on whether the
drive has 20, 40 or 60 GB capacity).
I've got one of these :
ad0: 39266MB IC35L040AVER07-0 [79780/16/63] at ata0-master UDMA66
If I turn tagged queueing on, I get an awful lot of write failures and
ata timeouts and whatnot. Basically it just doesn't work. **For me**
I'm not blaming Søren Schmidt here! it could be due to broken
hardware, code or just my sheer incompetence, but in the end I gave up
trying, it didn't work with my last drive either, and that was a 30GP
type drive (don't remember the model number though).
As far as I remember there are apparently problems with some of these
drives in terms of whether they even work when they leave the factory,
but I've only ever heard that here (make what you want of that).
Good luck, YMMV I think I might have made a local patch to include
my drive.. something like this...
/usr/src/sys/dev/ata/ata-disk.c around line 861
const char *drives[] = {IBM-DPTA, IBM-DTLA, IC35L040AVER07, NULL};
As I said, it didn't work though =(
Steve
P.S. let me know if you suceed in getting it to work, maybe I need a
different motherboard or just to change some settings or something?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD and Athlon Processors
In message [EMAIL PROTECTED] Terry Lambert writes: : Are you sure it's not just a CMD640 IDE controller? They are : known to have issues; Linux has a patch... FreeBSD used to, but : I think it got yanked out, or was just turned off by default. The CMD640 had many DMA corruption bugs. Many are fixed with the Linux patch, but data corruption issues remain. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SO_REUSEPORT on unicast UDP sockets
On Mon, 3 Sep 2001, Terry Lambert wrote: Similarly, there are a number of bugs in the TCP sockets as well; specifically, there's a problem with all sockets being treated as being in the same collision domain, when doing automatic port assignment. This limits you to 65535 oubound TCP connections, even though you have multiple IP aliases on an interface (theoretically, you should get 64k connections per IP address, if you bind _not_ to IN_ADDR_ANY, but instead use a specific port, but the hash is broken). I like this problem's evil sibling: client side TIME_WAITs. If you build them up, you just sit there unable to allocate outgoing ports until they time out. Maybe net or openbsd handle these situations better, I'll have to check later. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
