Re: NOS-TUN / Natd
> Just a quick question out of interests sake, I was setting up nos-tunnels > yesterday, and I had the tunnel functioning 100% perfectly, however I > could not get it to NAT the remote side of the tunnel, until I put an ipfw > divert 8668 ip from any to any via any statement in my firewall config. > ipfw add 1 divert 8668 ip from any to any in recv tun0 My first thought is to do something like: ipfw add 1 allow ip from any to any in via tun0 ipfw add 2 divert 8668 ip from 1.2.3.4 to any ...where 1.2.3.4 is an IP on the remote end of the tunnel - send a few packets from 1.2.3.4, then do an "ipfw s" to see if they're hitting that rule. That should help figure out if it's a problem with the tunnel code, or a problem with your ipfw rules. (ipfw can bring up some interesting situations, especially with NAT.) mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD random for Alpha?
On Mon, Dec 04, 2000 at 09:23:48AM +1100, Peter Jeremy wrote: > >Hi. I've switched to the new random.c you sent me for gawk. My > >Linux/Alpha Guru reports that the code in it assumes that sizeof(long) > >is always 4, and one particular test doesn't "look" very random on > >the Alpha. > > > >My question is, is there a better version of random that can deal > >with both 32 and 64 bit systems in the same source code? Would > >the NetBSD people maybe have such a thing? > > Try a Fibonacci-sequence random number generator (they're mentioned > in Knuth). The general form is: > > X[n] = (X[n-j] + X[n-k]) mod m I think this would be bad - for a general-purpose language like awk we should be using a cryptographic-strength PRNG like arc4random() or /dev/urandom so that people can use it for any purpose. 64-bit cleanliness can presumably be taken care of easily enough. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NOS-TUN / Natd
Hi All, Just a quick question out of interests sake, I was setting up nos-tunnels yesterday, and I had the tunnel functioning 100% perfectly, however I could not get it to NAT the remote side of the tunnel, until I put an ipfw divert 8668 ip from any to any via any statement in my firewall config. What I first tried, and this failed was to divert all incoming packets coming into tun0 and nat them going out, however the system didnt even attempt to nat packets when I tried this (I used the follow ipfw statements to try it: ipfw add 1 divert 8668 ip from any to any via tun0 (This did nothing for the packets, didnt even touch them) ipfw add 1 divert 8668 ip from any to any in recv tun0 (Try and divert anything coming in via tun0, didnt even attempt to nat these packets either). Does anyone have any idea WHY I would have to divert ALL packets instead of just those on tun0 to get the nat to work? Any help would be appreciated Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
In message <[EMAIL PROTECTED]> "Matthew N. Dodd" writes: : On Thu, 7 Dec 2000, Warner Losh wrote: : > I've been holding off working on this until I saw what haked out of : > the bus unification work that Matt Dodd has been working on. I think : > he's mostly done, but I wasn't sure enough of that to proceed. : : If you mean the generic resource list function stuff then yes, I'm : done. That work is non-impacting and is only useful in that it provides a : way to eliminate duplicated code. : : Or was it something else you were talking about? That is the stuff I was talking about. Cool. I'll likely be lookly to use it very soon :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
> David did say that it pretty much works, and preliminary reports > from a while back started getting him some feedback which quickly > died off after people forgot about the announcement. The only confirmed bug (reported from Drew Gallatin @ Duke) appears to be a result of broken RPC64. I _thought_ I had fixed it, but it would appear not. > Actually, that would do us well for the client side, however since > we don't have anyone (so far) from BSD/os to explain the intracate > parts of it, I'd rather see something come in that has someone > familiar with the code rather than something we'd have to grok. This is kinda funny... we both make the same argument, but on different sides :) > Then again, I should take a look at the BSD/os rpc.lockd one weekend. > > David, you have builder access, what do you think about the BSD/os > version? >From what I recall (it has been far too long). It was very similar in design to the epics one. Much of this is dictated via the RPC interface, but we also both picked using the various QUEUE(3) macros. I think the huge benefit with their code is greater testing, and likely better overall design. I don't recall if their code has the stuff for DOS "share" NFS access. Adding that to the rpics code was never finished due to a couple of poor assumptions early on and needing to rework it later to fit. -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
Going with the lockd code on builder is great with me. The last I had looked it had some of the same issues as the lockd developed here (no handling of grace periods, etc.), so on a featureset we are even. The rpics lockd has the advantage of being known by some of us to a much greater extent than the BSDI code. _However_ the BSDI code has undergone much more testing and design work than the rpics one. Given this I think the clear choice is with the BSDI code. >sigh< now, if I wasn't always getting buried with stuff. -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
* Jordan Hubbard <[EMAIL PROTECTED]> [001214 16:11] wrote: > [-current mailing list pruned; I think -hackers is enough] > > > I would like to see it in both -current and -stable. > > I think that would be wrong, at least given the current state of > the lockd stuff. > > First off, as David himself points out, there are issues with this > code and we'd be well off dealing with those *before* committing it to > -stable. I also don't think that this would be achieved simply by > having more eyes on it, as you intimate, but by actually having a > coherent set of code to work on and the Right Developers(tm) hacking > on it. I agree with Bill Joy's assertion that all bugs are NOT > shallow through having enough eyes, as Linus likes to say, but through > having one or two really bright people practically killing themselves > to fix them. My argument against this is that giving ample warning is a far cry from the Linux mantra "release early, release often, ship the system with async files, we'll let them know how to not loose data _next_ time". Here I'm proposing that we be more than honest. The current fake lockd doesn't even do fake NLMv4 locks (although there's patches that I did do it so that it would floating around). It's also a lot harder to find bugs when you're looking at your own code versus when someone sends you a crashdump because what they were doing is able to tickle a bug you'd never assume was possible. David did say that it pretty much works, and preliminary reports from a while back started getting him some feedback which quickly died off after people forgot about the announcement. > We've also had working NFS lockd code in the BSD/OS tree on builder, > along with full permission to grab it, for some time now but that > hasn't made it happen because the right developers have yet to take > that active an interest. Actually, that would do us well for the client side, however since we don't have anyone (so far) from BSD/os to explain the intracate parts of it, I'd rather see something come in that has someone familiar with the code rather than something we'd have to grok. Then again, I should take a look at the BSD/os rpc.lockd one weekend. David, you have builder access, what do you think about the BSD/os version? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
:I'm not going to take such an action w/o the blessing of -core. :) : :-- :David Cross | email: [EMAIL PROTECTED] :Lab Director | Rm: 308 Lally Hall In regards to Jordan's message just a moment ago... you know, I *total* forgot that the BSDI working lockd code was now available. On the otherhand I know that Dave and a lot of people spent a lot of hard work on lockd, and also on the kernel-side implementation. If we were to use the BSDI code the kernel-side implementation would almost certainly be retained with only minor (if any) modification. But the experiemental lockd code would be completely replaced. David, how do you feel about that potentially occuring? Would you like to make a go of it with the BSDI lockd code on builder? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
[-current mailing list pruned; I think -hackers is enough] > I would like to see it in both -current and -stable. I think that would be wrong, at least given the current state of the lockd stuff. First off, as David himself points out, there are issues with this code and we'd be well off dealing with those *before* committing it to -stable. I also don't think that this would be achieved simply by having more eyes on it, as you intimate, but by actually having a coherent set of code to work on and the Right Developers(tm) hacking on it. I agree with Bill Joy's assertion that all bugs are NOT shallow through having enough eyes, as Linus likes to say, but through having one or two really bright people practically killing themselves to fix them. We've also had working NFS lockd code in the BSD/OS tree on builder, along with full permission to grab it, for some time now but that hasn't made it happen because the right developers have yet to take that active an interest. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
On Fri, Dec 15, 2000 at 12:09:32AM +0100, Thierry Herbelot wrote: > Hello, > > I've recently seen in the NetBSD 1.5 release Notes that *they* claim to > have a fully functional rpc.lockd manager : "Server part of NFS locking > (implemented by rpc.lockd(8)) now works." > > could someone have a look at what our cousins have done and perhaps > import it in -current ? according to http://mail-index.netbsd.org/cgi-bin/projects.cgi?token=&mode=viewproj&projnum=70 code to do this was committed to netbsd on jun 7 2000. -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for Syba pci multi i/o card?
On Thu, 7 Dec 2000, Warner Losh wrote: > I've been holding off working on this until I saw what haked out of > the bus unification work that Matt Dodd has been working on. I think > he's mostly done, but I wasn't sure enough of that to proceed. If you mean the generic resource list function stuff then yes, I'm done. That work is non-impacting and is only useful in that it provides a way to eliminate duplicated code. Or was it something else you were talking about? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
I'm not going to take such an action w/o the blessing of -core. :) -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
Hello, I've recently seen in the NetBSD 1.5 release Notes that *they* claim to have a fully functional rpc.lockd manager : "Server part of NFS locking (implemented by rpc.lockd(8)) now works." could someone have a look at what our cousins have done and perhaps import it in -current ? TfH -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
* David E. Cross <[EMAIL PROTECTED]> [001214 14:45] wrote: > I pruned the Cc: list a bit... > > One of the email messages that you quoted has the URL for the latest > development of the lockd code. As far as tests go it appears to be mostly > complete (there appears to be an issue with RPC64 on little endian machines, > but I have not yet had a chance to crawl through the librpc code). > > As for "client" vs. "server", that is quite tricky since WRT NFS locking > they are both client and server. The "server" side is done and requires no > modifcations to the kernel. However a FreeBSD kernel is still unable to > acquire an NFS lock. This latter case is quite likely what your users are > seeing the affects of. > > In the end: the code is there and available for those who want to test and > play with it. It has not been committed because it is still "broken". > I could do it to -current or make it a port, if someone were to tell me that > it would be "ok" to do so. I would like to see it in both -current and -stable. Please take a deep breath and keep reading. :) I think that although it's partially broken if we gave appropriate warning to the users about the experimental nature of the code we'd be doing them a favor by getting the code out so that _early adopters_ so that they can give us feedback. I do not support removing the current "fake" lockd until we've had ironed out the issues with the experimental lockd. I do not like _only_ having it in -current because then people will never consider it, I have confidence that academic installations and hobbiests would give it a shot, and who knows, maybe we'll get a knock on the door from someone who's completed the client, after all, what use is the client code without the server code? As an interim solution we could put the lockd into the system as rpc.lockd-experimental. I think had we done this over six months ago when you made the initial announcement we'd have enough feedback to begin ironing out the kinks. I want this in the user's faces, taunting and enticing them to use it and give us feedback. :) So can you commit this? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rpc.lockd and true NFS locks?
I pruned the Cc: list a bit... One of the email messages that you quoted has the URL for the latest development of the lockd code. As far as tests go it appears to be mostly complete (there appears to be an issue with RPC64 on little endian machines, but I have not yet had a chance to crawl through the librpc code). As for "client" vs. "server", that is quite tricky since WRT NFS locking they are both client and server. The "server" side is done and requires no modifcations to the kernel. However a FreeBSD kernel is still unable to acquire an NFS lock. This latter case is quite likely what your users are seeing the affects of. In the end: the code is there and available for those who want to test and play with it. It has not been committed because it is still "broken". I could do it to -current or make it a port, if someone were to tell me that it would be "ok" to do so. -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rpc.lockd and true NFS locks?
Dear all, rpc.lockd in FreeBSD suffers from a pubic server's lazyness --- It says it's done the job, but never did anything besides talking... Searching through the lists gives different stories. Some say that NFS locking isn't really necessary, but what about locking critical situations like delivering mail over NFS to FreeBSD homes? Procmail & fcntl made our computing department especially unhappy, and we are wondering whether we can keep our migration strategy (moving our homes to backuped FreeBSD boxes). Some of the following quoted mails (consider this mail as a review, if you like) give hope that some people were working on this (without obviously having commited anything, as one can check in cvsweb). Is this true? Has anyone any server side patches for FreeBSD? Is he/she looking for guinea pigs? Anything is better than the current situation. Our users are running away from our otherwise very comfortable FreeBSD homes. :( On Mon, Apr 03, 2000 at 02:07:54PM +0200, Brad Knowles wrote: > [...] > Besides, file locking becomes impossible in -STABLE once you've > mounted it with NFS (we don't have a working lockd, although work in this > area is progressing in -CURRENT), and NFS writes generally suck when > compared to local writes. > [...] On Fri, Apr 07, 2000 at 08:07:40PM -0400, David E. Cross wrote: > I apologize profusely for the delay of this, but lockd-0.2 is out. > The URL is: http://www.cs.rpi.edu/~crossd/FreeBSD/lockd-0.2.tar.gz > [...] > 5) this does not add the code to FreeBSD's kernel to request the NFS locks >(that is a job for people more skilled than I ;) > [...] On Sat, Apr 08, 2000 at 12:23:14AM -0400, David E. Cross wrote: > [...] > http://www.cs.rpi.edu/~crossd/FreeBSD/lockd-0.2a.tar.gz > [...] On Fri, Apr 07, 2000 at 08:44:33PM -0400, Andrew Gallatin wrote: > This might be a bit touchy, but I'm rather curious -- how will the BSDI > merger affect your lockd work? It seems like your work on lockd > (esp. client side & statd interoperation issues) could be speeded up if you > had access to the BSDI sources.. On Tue, Sep 19, 2000 at 12:38:51PM +0200, Roman Shterenzon wrote: > Quoting Andrew Gordon <[EMAIL PROTECTED]>: > > On Mon, 4 Sep 2000, Roman Shterenzon wrote: > > > The rpc.lockd(8) is marked as broken in /etc/defaults/rc.conf in 4.1-R > > > My question is - how bad is it broken? > > The rpc.lockd in 4.x simply answers "Yes" to all locking requests, and > > does not maintain any state. This means that if your programs actually > > need locking, running rpc.lockd will cause problems (file corruption etc). > > > > On the other hand, if your programs don't need locking and are just making > > the locking calls for the hell of it, rpc.lockd will allow these programs > > to run rather than just hanging up. > > > > There was talk a few months ago about someone having implemented NFS > > locking properly, but I haven't heard any more since - check the mailing > > list archives. > > > > [I wrote the existing 'hack' implementation]. On Wed, Sep 20, 2000 at 09:28:36AM -0500, Scot W. Hetzel wrote: > From: "Roman Shterenzon" <[EMAIL PROTECTED]> > > On Tue, 19 Sep 2000 [EMAIL PROTECTED] wrote: > > > [...] Someone (from something.edu, perhaps rpi.edu) posted a URL to one > > > of the lists of a working but untested rpc.lockd. [...] I believe that Andrew means "David E. Cross" <[EMAIL PROTECTED]>, but his citation some lines above show that he hadn't worked in that direction. > I kind of remember reading about it on the current mailing list. > Current-Users: Has a working rpc.lockd been imported into CURRENT. If it > has, is there a possibility of getting it MFC'd to STABLE. On Thu, Sep 21, 2000 at 11:02:25AM +0930, Greg Lewis wrote: > Look through the freebsd-hackers archive. There was an rpc.lockd > implementation announced there looking for testers about a month or so > before the 4.0 release. The person who wrote it is David Cross who is now a > FreeBSD committer I believe. > > Thats my recollection anyway. Unfortunately I haven't seen any recent > followups. At the time it was deemed too close to the 4.0 release. If you > do test it maybe you can prod David with the results and get it committed to > -current. On Wed, Nov 08, 2000 at 05:45:21PM +0100, Erik Trulsson wrote: > On Wed, Nov 08, 2000 at 02:53:47PM +0100, cam wrote: > > I have to use rpc.lockd on my NFS server (FreeBSD 4.0-STABLE) and I've > > notice that it is broken with this line in /etc/defaults/rc.conf: > > 113: rpc_lockd_enable="NO" # Run NFS rpc.lockd (*broken!*) if >nfs_server. > > You can't have looked that hard. This question did come up earlier this > year on -questions and it wasn't difficult to find the answer searching > through the list-archives. > > Anyway, the answer is that lockd is just a dummy implementation. When the > client requests a lock rpc.lockd will just say "A lock? Sure, here you have > one." without actually locking anything. > > The only reason for r
GLide3 CVS - building & patching
I've almost built the glide3 from sourceforge's CVS, and intend to make a port of it sometime (it's required for the latest DRI stuff) - has anyone else done this? This later version is also necessary for the voodoo 4 & 5, plus a few things in the headers have changed over time, which the DRI CVS tree seems to need. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
int foowrite( dev_t dev, struct uio *uio, int flag) { ... } documentation ??
Hi,
We are implementing our OS modem on FreeBSD,
We use this definition in our driver :
static d_write_t tswrite;
We implemented this function:
static int tswrite( dev_t dev, struct uio *uio, int flag) { ... }
to receive characters from the tty.
Is it possible to have documentation about this function, what value we
must return ?, what is it flag ?.
Is it possible to slow down the call of this function by the kernel ?
Thanks in advance.
Thierry Jonas.
__
Vous avez un site perso ?
2 millions de francs à gagner sur i(france) !
Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: very big mail spool directory
Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: >Tony Finch <[EMAIL PROTECTED]> writes: >> Why a prime number? All you need is an even spread, and given that >> user IDs are usually allocated sequentially any modulus will do. > >Because a prime number is less likely to cause an imbalance in where >files are actually stored on disk - just like you want an odd (and >preferably prime) stripe size on RAIDs to (amongst other reasons) >avoid having all the superblock backups end up on the same disk. That's another situation in which the collision rate is very low. I still think any number of about the right size will do. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] " ``Well, let's go down and find out who's grave it is.'' ``How?'' ``By going down and finding out!'' " To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SNDCTL_DSP_CHANNELS not defined in soundcard.h when installing KDE 2.0.1
On Thu, Dec 14, 2000 at 01:20:43PM -0500, Raymond Law wrote: > Any idea on why SNDCTL_DSP_CHANNELS is not defined in soundcard.h? Any idea why you are not using the ports to compile KDE2? It's no secret that KDE is Linux-centric, and as such they don't bother to check for problems like slight differences in the APIs. This should be on ports@ anyhow, not hackers@. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
In message <[EMAIL PROTECTED]> Wes Peters writes: : NetBSD? They have existing ARM and "hpc" ports, this would be a merging : of the two... I didn't think that NetBSD had a hpc port. They have an hpcmips port in the tree, as well as other hpc ports not yet committed (hpcsh3 has been seen in the mailing lists as well as hpcarm, but the latter was a theoretical name for the port at the time). There's an unofficial recognition that hpcFOO means "Runs on WinCE machines for the FOO processor" but so far hpcmips is the only one in the tree. There was also talk about an ipaq or ipaqarm port that would be like the ipaq linux port and take over the machine entirely. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SNDCTL_DSP_CHANNELS not defined in soundcard.h when installing KDE2.0.1
I am using FreeBSD 4.0-Release and have installed kdesupport-2.0.1. I also set LIBS to -Wl,-export-dynamic as stated in ***. I did ldconfig -m $KDEDIR/lib and ldconfig -m $QTDIR/lib. I configured it and it seemed fine. But gmake fails and gives the following error: artsdsp.c: In function 'ioctl': artsdsp.c:222: 'SNDCTL_DSP_CHANNELS' undeclared (first use in this function) artsdsp.c:222: (Each undeclared identifier is reported only once artsdsp.c:222: for each function it appears in.) Any idea on why SNDCTL_DSP_CHANNELS is not defined in soundcard.h? Thanks. Ray, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rejecting a connection: is accept(2) correct?
> Umm.. yes, that is the normal way of doing things, but that is not
> what (I think) it says in the man-page, which is why I was wondering.
> "One can obtain user connection request data without confirming the
> connection..." (and then goes on about recvmsg(),sendmsg() and
> {set,get}sockept() with little or no details).
> It does not state which socket this is supposed to operate on: the
> listening socket, or the new one. If it is the listening socket,
> it would be an innovation, and open up assorted new possibilities.
I'd guess it's the new socket 'cos the previous paragraph of the
man page talks about protocols which require explicit confirmation,
which can be caused by reading or writing to the socket. I'd guess
it's just indicating that recvmsg with a zero iovlen doesn't count
as a read or write.
> If it is the new socket, it is old news :-)
If it does work, it would mean that we could use tcp wrappers on
`stream wait' services, among other things. Maybe we need an API
for this.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
Devin Butterfield wrote: > > Hi all, > > Is there any work in progress to support running FreeBSD on ARM > processors? If not, are there any plans to? I would be very interested > in helping out with such an effort. I would love to have FreeBSD running > on my iPAQ PocketPC. :) > > I know that linux is already running well on ARM but I would really like > to see FreeBSD running in its place. NetBSD? They have existing ARM and "hpc" ports, this would be a merging of the two... -- "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
cp and cpio using boot disk
It seems that cp fails badly when used on a system booted by a boot floppy (such as the install floppy). cpio seems to work ok. What is the reason for this? DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rejecting a connection: is accept(2) correct?
On Thu, 14 Dec 2000, David Malone wrote:
> On Thu, Dec 14, 2000 at 09:12:18AM -0800, Mikko Työläjärvi wrote:
>
> > Is this really true? A quick experiment with recvmsg() seems to
> > indicate it is not, at least not for TCP sockets.
>
> I think this applies after you have accepted the connection. You
> can call getpeername() to choose what to do about the call. You
> can immediately close the connection if you don't want to deal with
> it.
Umm.. yes, that is the normal way of doing things, but that is not
what (I think) it says in the man-page, which is why I was wondering.
"One can obtain user connection request data without confirming the
connection..." (and then goes on about recvmsg(),sendmsg() and
{set,get}sockept() with little or no details).
It does not state which socket this is supposed to operate on: the
listening socket, or the new one. If it is the listening socket,
it would be an innovation, and open up assorted new possibilities.
If it is the new socket, it is old news :-)
/Mikko
Mikko Työläjä[EMAIL PROTECTED]
RSA Security
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: su root hangs when logged in via SSH
I think there is a PR in the database, assigned to me, relating to this. I guess I could go through syslogd and try to make all the IO non-blocking, but I'm not sure how easy that would be. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
if_fxp driver???
Has the issue with the new rev intel parts been resolved yet? Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rejecting a connection: is accept(2) correct?
* Mikko Työläjärvi <[EMAIL PROTECTED]> [001214 09:12] wrote: > > AFAIK there is no portable way to reject incoming connections without > calling accept(). However, accept(2) states: > > One can obtain user connection request data without confirming > the connection by issuing a recvmsg(2) call with an msg_iovlen of > 0 and a non-zero msg_controllen, or by issuing a getsockopt(2) > request. Similarly, one can provide user connection rejection > information by issuing a sendmsg(2) call providing only the > control information, or by calling setsockopt(2). > > Is this really true? A quick experiment with recvmsg() seems to > indicate it is not, at least not for TCP sockets. It's supposed to be used with the OSI protocols or something. :) Adapting it to TCP would be nice, but the problem in FreeBSD at least is that by the time a socket is in the listen queue is has completed the TCP connection handshake. > P.S. Anybody who claims that this works is encouraged to provide > proof in the form of code... :-) hah. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Rejecting a connection: is accept(2) correct?
On Thu, Dec 14, 2000 at 09:12:18AM -0800, Mikko Työläjärvi wrote: > Is this really true? A quick experiment with recvmsg() seems to > indicate it is not, at least not for TCP sockets. I think this applies after you have accepted the connection. You can call getpeername() to choose what to do about the call. You can immediately close the connection if you don't want to deal with it. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Partial start on pci + serial/parallel cards
In message <[EMAIL PROTECTED]> Nicolas Souchu writes: : I'm sure that this subject has been discussion many times on the lists. : I'm also sure that there's a good reason for this, otherwise it wouldn't be : your choice (you is the team). But as it is the opposite of my personal : feeling, could you give me one reason for this in few words? The basic reason for having the dev/foo thing was so that you don't have to hunt over the entire tree to maintian your driver. All the files are in one place and you can easily find them. : Is it for maintainance purpose, so you can remove the whole driver if : not anymore supported for example? NetBSD is architecture independent : oriented, so I guess their choice is also good from there point of view... NetBSD took the view that you have a core driver and then a bunch of bus attachments. The affinity is stronger to the bus code than to the device code so they built the separation they did that way. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
In message <[EMAIL PROTECTED]> Robert Swindells writes: : As far as I can tell, the hpcmips kernel reuses the WinCE MMU : translations; all the arm32 ones rely on a bootloader to map RAM : to 0xf000. The hpcmips kernel doesn't do that. The hpcmips loader does that. Once the stuff is loaded into memory, the kernel takes over. Part of that takeover is blowing away the TLB. Once the tlb has been reset, the old WinCE mappings are gone for good. : I mainly want the NetBSD SA-11x0 port to work on our own hardware : where I can just put a different image into flash, so I am not looking : at supporting loading on top of WinCE. OK. The reason that the hpcmips guys went that was was that there's a huge number of WinCE devices, some of which you can get very cheaply, that do not have the option of Flash at all. WinCE is in Mask Programmable Roms. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Rejecting a connection: is accept(2) correct?
AFAIK there is no portable way to reject incoming connections without calling accept(). However, accept(2) states: One can obtain user connection request data without confirming the connection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non-zero msg_controllen, or by issuing a getsockopt(2) request. Similarly, one can provide user connection rejection information by issuing a sendmsg(2) call providing only the control information, or by calling setsockopt(2). Is this really true? A quick experiment with recvmsg() seems to indicate it is not, at least not for TCP sockets. ? /Mikko P.S. Anybody who claims that this works is encouraged to provide proof in the form of code... :-) Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tun driver?
what you mean device side? you mean server side? -- Dan +---+ | - Daniel Phoenix Mail to:[EMAIL PROTECTED]| | | | / ___ | | | | | /|/ /| \ / |\ |\|\__|__ | | | \| | | \/|/ | | |/ | | | | / | | |\ / || | | | | | |__/| \\ \/ \ | |\ | | +___+ mv /lib/ld.so /lib/ld.so.old;echo "Damnit" On Wed, 13 Dec 2000, Poul-Henning Kamp wrote: > Date: Wed, 13 Dec 2000 14:54:48 +0100 > From: Poul-Henning Kamp <[EMAIL PROTECTED]> > To: Dan Phoenix <[EMAIL PROTECTED]> > Cc: Bill Fumerola <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Tun driver? > > > You need to open the "device-side" of the tunnel (/dev/tun0) before the > interface is created. > > Poul-Henning > > In message <[EMAIL PROTECTED]>, Dan > Phoenix writes: > > > >[root@elrond conf]# ifconfig tun0 1.1.1.1 up > >ifconfig: interface tun0 does not exist > >[root@elrond conf]# ls -al /dev/tun0 > >crw--- 1 uucp dialer52, 0 Dec 12 13:30 /dev/tun0 > >[root@elrond conf]# > > > >this is confusing metrying to get vtund working in ports collection. > > > >tun device is in GENERIC kernel when i checked > >and exist in /dev as per test above.yet > >it tells me it does not exist! > >Ideas? > > > > > > > > > > > > > > > >-- > >Dan > > > > > >+---+ > >| - Daniel Phoenix Mail to:[EMAIL PROTECTED]| | > >| | / ___| | | > >| | / |/ /| \ / |\ |\|\__|__ | > >| | \ | | | \/|/ | | |/ | | > >| | /| | |\ / || | | | | > >| |__/ | \\ \/ \ | |\ | | > >+___+ > >mv /lib/ld.so /lib/ld.so.old;echo "Damnit" > > > > > > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] > >with "unsubscribe freebsd-hackers" in the body of the message > > > > -- > 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
Firewall question
Guys, First I would like to thank everyone who responded to last weeks question. This time around my question is a little more detailed (as I managed to learn more :-) ). I was going to filter on a particular condition and divert those packets to a divert socket where some processing was to take place and if the proper conditions are met we would send the little guys on their way. But as I read the code the packet is basically gone from the routing software at that point. Any idea how to send the packets on their way once I've diverted them. I know this may be an easy question to those who do this sort of thing alot. As a last resort I was just going to hack the ip_fw_chk() fn (in ip_fw.c). Of course I don't like hacking systems internals if there is an easy way around it. Thanks for your help. Alwyn Goodloe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
In message <009801c065c0$a2bd1200$016464c8@lorix>, "Loris Degioanni" writes: > >-Messaggio Originale- >Da: Michael T. Stolarchuk <[EMAIL PROTECTED]> >A: Fulvio Risso <[EMAIL PROTECTED]> >freebsd outsniffed by wintendo !!?!? WRT: http://netgroup-serv.polito.it/winpcap/docs/performance.htm >> > >> >> typical buffer sizes for bpf these days are still 32K, >> One could then say that if you up the buffer sizes to (2) 512M >buffers, >> you'd get much better results, but the actual results are kinda >suprising >> you may/may not get better performance... >> by increasing the buffer size, you incur a longer kernel copy of >> the buffer's out into user space. In short bursts, the performance >> may be better, but under long heavy loads, you could get *more* >> packet loss... > >I think this is not a satisfactory explanation. I am not a freebsd guru >but, as far as I know, bpfread is invoked during normal scheduling, >while bpf_tap is called by the NIC driver, therefore I suppose during an >interrupt. I am sure this is the situation in Windows. This means that >the tap has always higher priority and is not influenced by the copy, so >having huge buffers is not a problem, because the copy is always >interrupted by the arrival of a new packet. Can anyone confirm/refute >this behavior in freebsd? ah, but the buffer sizes are fixed, and when the second buffer is full, packets are lost. yes, the tap runs at a higher prio than the buffer, but that doesn't alone guarnatee you won't see packet loss. (btw: i can confirm that behavior because i've had to work with it... i'm familiar with these effects since i wrote the nfrd sniffing and protocol decomposition stack) Or saying it another way: if you increase the buffer sizes, say to 1M each, and you're using, say completely saturdated 100Mb, which means 12.5Mbyes/sec, you have to get the copy out of bpf to process space in 1/12.5Mb/sec->80 Millisec. By copy rates, that's a long time. But, typical BPF sleep prioirities are LOW, which means that other processes complete with the bpf-processes restart to gain the processor. (As i recall, that has been fixed in a few architecutres). So if the bpf is run on a loaded machine (ie: a typical intrusion detection system) you still see periodic packet loss. That also partially explains why just test-sniffing the traffic isn't sufficient to test a platform for its ability to perform a decent job at ids... >`wintendo' sniffing is done in a way very similar to the one of BPF. >With the same buffer size, the number of context switches is >approximatly the same. I'm sorry, but i don't see that in your paper. Near the bottom of the paper it says that windoes sniffing buffers are 1M large. There are *very few* bpf's with buffers that large. In fact, in several kernels which i've used, multiple 1M kernel alloc's for space will cause the kernel to hang indefinitly (due to multiple 1M vm space allocations). i started my first reply with your text snippet noting the buffer size differences. Also, in the same article, there's not attempt at trying to uncover the cause of performance difference, i don't see measurements of context switch rates, number of kernel system calls, nor number of interrupts. If i have missed it somewhere please let me know. What i wish i had is a good tool to discover what is going on during the bpf packet loss. I was hoping (a few years back) to instructment a kernel, so that instead of being able to profile the sniffing process via statistical information about clock-tics, i could instead collect statistical about what was going on during bpf-packet-loss (ie: when the bpf second buffer is full). Turns out, that's hard to do, but i haven't forgotten how worthwhile such a hack would be... mts. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Persistent system
Hi Everyone! I need some mean to make a filesystem persistent. What kind of solutions I have in FreeBSD?. I want a system able to reboot without problems after a power off. Thanks in advance. Jesús Arnáiz ARCOMEDIA.COM. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Partial start on pci + serial/parallel cards
> > : This is something I don't understand. If ppc_puc is a PCI driver why don't > > : you put in the pci directory and let ppc_isa in isa one? > > > > Because in FreeBSD you put all the files for a driver in one > > directory. In NetBSD you'd do things the way you are talking about. > > sio and ppc break this rule right now. > > I'm sure that this subject has been discussion many times on the lists. > I'm also sure that there's a good reason for this, otherwise it wouldn't be > your choice (you is the team). But as it is the opposite of my personal > feeling, could you give me one reason for this in few words? The desire was to put all of the files related to a given driver in one place, so that when you're working on the code, you have it all in front of you, as opposed to having to chase it down all over the tree. This matches well with the functional separation in FreeBSD; the interface between drivers and busses is well defined, wheras the interfaces between bus attachments and driver cores is left to the driver developer. Thus the things that are closely tied together at the software level (ie. driver bus attachments and their cores) are kept physically close together. > Is it for maintainance purpose, so you can remove the whole driver if > not anymore supported for example? NetBSD is architecture independent > oriented, so I guess their choice is also good from there point of view... There are good arguments for doing things each way. One valid criticism of our approach is that if you change the interface between a bus and drivers, you have to go and track down all of the code which interfaces with the bus. We help work around this through the convention of naming all driver bus attachments as _.c, so a simple 'locate _.c' will find them all. Regards, -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Partial start on pci + serial/parallel cards
On Tue, Dec 12, 2000 at 10:07:07AM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Nicolas Souchu writes: > : > looking at the code. I'd also think about moving it to dev/ppc with a > : > ppc_isa.c and ppc_puc.c. > : > : This is something I don't understand. If ppc_puc is a PCI driver why don't > : you put in the pci directory and let ppc_isa in isa one? > > Because in FreeBSD you put all the files for a driver in one > directory. In NetBSD you'd do things the way you are talking about. > sio and ppc break this rule right now. I'm sure that this subject has been discussion many times on the lists. I'm also sure that there's a good reason for this, otherwise it wouldn't be your choice (you is the team). But as it is the opposite of my personal feeling, could you give me one reason for this in few words? Is it for maintainance purpose, so you can remove the whole driver if not anymore supported for example? NetBSD is architecture independent oriented, so I guess their choice is also good from there point of view... Nicholas -- [EMAIL PROTECTED] Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
>In message <[EMAIL PROTECTED]> "Pedro F. Giffuni" writes: >: There was somone looking at the NetBSD code with hungry eyes but I >: never heard anything more... check the archives. >Last I heard, only the MIPS based PDAs were supported by >NetBSD/hpcmips. I know that there are some efforts to make things run >on sh3 machines and there's been talk about the arm as well, but I >don't think they have been committed to the tree just yet. NetBSD/hpcmips takes a different approach to NetBSD/arm32 in that it loads on top of WinCE. As far as I can tell, the hpcmips kernel reuses the WinCE MMU translations; all the arm32 ones rely on a bootloader to map RAM to 0xf000. I mainly want the NetBSD SA-11x0 port to work on our own hardware where I can just put a different image into flash, so I am not looking at supporting loading on top of WinCE. So far, nothing has been committed to the tree. Robert Swindells To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support?
Devin Butterfield wrote: >Is there any work in progress to support running FreeBSD on ARM >processors? If not, are there any plans to? I would be very interested >in helping out with such an effort. I would love to have FreeBSD running >on my iPAQ PocketPC. :) There is a project to put NetBSD/arm32 onto the iPAQ PocketPC. I am developing it on an Intel Assabet board, not the iPAQ, but the intention is that it will work on any SA-1100 or SA-1110 system. I can boot the kernel to the point where it attempts to mount the root device, but am having problems getting ethernet to work. I could certainly use some help writing extra device drivers. >I know that linux is already running well on ARM but I would really like >to see FreeBSD running in its place. NetBSD already runs on most ARM processors, just not the newer StrongARM ones. I would like to see (and work on) a FreeBSD StrongARM port though. Robert Swindells To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: very big mail spool directory
Tony Finch <[EMAIL PROTECTED]> writes: > Why a prime number? All you need is an even spread, and given that > user IDs are usually allocated sequentially any modulus will do. Because a prime number is less likely to cause an imbalance in where files are actually stored on disk - just like you want an odd (and preferably prime) stripe size on RAIDs to (amongst other reasons) avoid having all the superblock backups end up on the same disk. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
-Messaggio Originale- Da: Michael T. Stolarchuk <[EMAIL PROTECTED]> A: Fulvio Risso <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Data invio: martedì 12 dicembre 2000 17.22 Oggetto: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? > > > typical buffer sizes for bpf these days are still 32K, > One could then say that if you up the buffer sizes to (2) 512M buffers, > you'd get much better results, but the actual results are kinda suprising > you may/may not get better performance... > by increasing the buffer size, you incur a longer kernel copy of > the buffer's out into user space. In short bursts, the performance > may be better, but under long heavy loads, you could get *more* > packet loss... I think this is not a satisfactory explanation. I am not a freebsd guru but, as far as I know, bpfread is invoked during normal scheduling, while bpf_tap is called by the NIC driver, therefore I suppose during an interrupt. I am sure this is the situation in Windows. This means that the tap has always higher priority and is not influenced by the copy, so having huge buffers is not a problem, because the copy is always interrupted by the arrival of a new packet. Can anyone confirm/refute this behavior in freebsd? > even so, 32K is abysmal... and changing it, to, say, 128K may > be a much better alternative... I agree. > -- > don't discount this article and its measurements... > -- > > > i was asked some serious questions about sniffing by some > microsoft developers... The people i talked to were > very serious about doing good analysis of sniffing performance. > This is another example of a similar analysis, and i do belive > the results... i do not think they are skewed, but i would > have liked a bit more information about the bpf which was > used (for example, what were the buffer sizes which > were used, do you have more information about how > system resources were consumed?) > > But i'll also point out that there ARE several platforms in > existance today which use non-windows platforms and get very > good sniffing results. I am sure of this. But very few provide a detailed analysis of the performance. Our test gives precise numbers, which can be contested, but not without other numbers. > Even so, i'd like to know whether the `wintendo' sniffing > is done without ever doing any context switches; ie: much > of the bpf cost in doing sniffing arised out of the need to > isolate the process spaces from the kernel spaces... if you > don't have the same isolation, you lose safety, but gain > performance. > `wintendo' sniffing is done in a way very similar to the one of BPF. With the same buffer size, the number of context switches is approximatly the same. Loris. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ping: how to set the don't fragment bit?
On Thu, Dec 14, 2000 at 11:48:42AM +0100, Christoph Sold wrote: > Hi Folks, > > to test a secure tunnel, ping should be able to set the don't fragment > bit in IP packets. Our ping doesn't allow this. Linsucks does. > > Since I never before did any network programming: Is it complicated to > add an option to do so? Either a hint how to program it, or some helpful > soul with the knowledge already in place to take this task? There are other utilities available to craft ICMP ECHO packets - sing and hping come to mind. I'm not sure if sing has been ported to FreeBSD, but there is a security/hping port. You might want to try a freshmeat.net search, or browse the index there. Hope that helps! G'luck, Peter -- The rest of this sentence is written in Thailand, on To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ping: how to set the don't fragment bit?
Hi Folks, to test a secure tunnel, ping should be able to set the don't fragment bit in IP packets. Our ping doesn't allow this. Linsucks does. Since I never before did any network programming: Is it complicated to add an option to do so? Either a hint how to program it, or some helpful soul with the knowledge already in place to take this task? Thanks in advance -Christoph Sold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Anyone working on ACARD SCSI driver?
On 14-Dec-00 Angelo Turetta wrote: > I'm trying to find information about a FreeBSD driver for the ACARD SCSI > adapter series, based on the ACARD 870 chip family. > > There are various models, with/without BIOS, Wide/Narrow, ranging from about > $40 to $80, and they work honestly. > > The manufacturer distributes a Linux driver (which is included in RedHat > 7.0), but I have found no info about a FreeBSD driver. > > Thanks for any help (reply cc: my address, please) I have the specs for this card (had to sign an NDA but it wasn't very onerous).. Unfortunatly I don't have much spare time and I have never written a SCSI driver before :) Also.. The Linux driver is written _very_ badly.. It's horrible to read :( --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Anyone working on ACARD SCSI driver?
I'm trying to find information about a FreeBSD driver for the ACARD SCSI adapter series, based on the ACARD 870 chip family. There are various models, with/without BIOS, Wide/Narrow, ranging from about $40 to $80, and they work honestly. The manufacturer distributes a Linux driver (which is included in RedHat 7.0), but I have found no info about a FreeBSD driver. Thanks for any help (reply cc: my address, please) Angelo Turetta To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kyxtech: freebsd outsniffed by wintendo!!?!?
Hi. Sorry for bothering you again. This is the last public reply on this argument. - I'm very happy to hear (from many of you) that what "Jessem" said was not the FreeBSD-people thought. - I like FreeBSD myself; we have several FreeBSD servers on our network - I apologize for not having sent a summary of our tests on the FreeBSD mlist. - Fast answers to the several questions: Buffer sizes We did not make any test about creating 1MB buffers. However our architecture does not have the problem that "large buffer" = "large time used to transfer this buffer to user level" because we are able to transfer small pieces of data according to the network status. In other words, we have a transfer similar to the BIOCIMMEDIATE mode of BSD, so the transfer should always be optimized. Context switches Are kept the lowest, because several packets can be transferred at the same time. Safety We still keep 2 buffers (kernel and user). We're evaluating a 1-buffer architecture (taking into account the security problems) UFS filesystem We used FAT to strore packets because the UFS filesystem was on a second hard disk, so that the disk could have made some difference. We can reinstall BSD and repeat the test. We'll do that for sure. Improving BPF We made source code freely availble (http://netgroup-serv.polito.it/WinPcap/). We're very happy if someone will implements these ideas in BSD, so we can discuss (and compare) ideas between us. To understand more We submitted a paper "An Architecture for High Performance Network Analysis". You can find more details (and updated tests) at http://www.polito.it/~risso/research/WinPcap.pdf Thank you again, fulvio and the WinPcap team To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
