POSIX compatibility issue
Can someone take a look at this PR ? http://www.freebsd.org/cgi/query-pr.cgi?pr=30317 It's necessary to fix compilation issues for a POSIX compliant Java VM, that uses sockets. There are similar open bug reports against NetBSD too, without any comments on why this change can not be made. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[4]: auto relaying for subdomains -- why?
poige>> Yes, I saw this info here: poige>> http://www.sendmail.org/m4/features.html#relay_mail_frombut most poige>> valuable part of my question was about the purpose or the idea behind poige>> this, cause it's not too clear to me why allowing relaying for domain poige>> FOO.BAR should allow relaying for SUB.FOO.BAR? > Because some places have only one machine (firewall) that accepts mail from > the outside world for all of the hosts inside the network. For example, in > my previous life as a sysadmin at WPI, only smtp.wpi.edu would accept > incoming mail for all of the machines (> 3000) on campus. I'd much rather > say "wpi.edu" in one place instead of listing loads of subdomains > (ee.wpi.edu, me.wpi.edu, res.wpi.edu, ...). Not too close to question again... I understand this (this is the need to easily cover all the domain and as I wrote in the initial letter "...I can accept this as reasonable behavior..." having in mind just the same reason you're talking about). But that time I wasn't sure whether it is a SENDMAIL's feature (local configuration as you said after) or it's required/described in RFC. This was the start :) Now it's all clear :) and I understand that it was just a way SENDMAIL's is configured. Another question could be why not to use syntax .foo.bar instead of foo.bar but I'm quite ready to call it a rhetorical one ;-)) (regexps are also there ;-) poige>> I mentioned RFCs because I had a hope to find out the answer from it poige>> but still haven't yet... > RFC's cover protocols over the Internet, not local configuration or policy. But who could say these early hours that such behavior isn't dependant on protocol? :-)) P.S. Thank you everybody, your answers have thrown some additional light upon the subject deepness! ;-) -- P.P.S. I'm not quite sure should I start new thread or can remain within it with another question which is: What MTA software supports highly configurable relaying... One of the needed features is a support for using alternative mail routers (relays) in case when this MTA can't send a message by itself because of networks problem. For example situation could be: MTA is on a network A which is temporarily cut off from it's uplink so it can't transfer mail by itself, but it has a connection (permanent or dial-up) to another mailer. Are there such MTAs which can be said "if you can't send it by yourself (would be cool if additional parameters were some_time_period and failure_reason) then use that MTA (ip-addr) or that (another-ip)?". I suspect in common case such "system" could easily lead to loops and have other drawbacks but in such simple configuration it seems all should work fine... -- Igormailto:[EMAIL PROTECTED] 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 ?
On Thu, Sep 06, 2001 at 06:40:01AM +0200, Thierry Herbelot wrote: > > On Wed, Sep 05, 2001 at 09:33:55PM +0200, Thierry Herbelot wrote: > > > "known-bad" revision for these babies -, and the 762 North Bridge of the > > > soon to be there SMP Athlon) > > > > "Soon to be there"?? Hum... I'm typing to you from one. > > Excuse me : I meant for the common mortal, with prices more in line with > what can be expected from Asus or Abit These *are* prices for common mortals: Tyan Tiger 760MP mobo $220 2x Palomino 1.2GHz MP $160 x 2 total: $540 Surely one can afford that. Heck the K6-2/450 I used for 2.5 years cost me $225 and the Tyan Trinity100 mobo was like $125; that was $350 just for that. OR go with the Tyan Thunder 2/dual 10/100 NICs + dual U160 SCSI for $445 this board also has on-board ATI VGA video. All you need with this board is 2x CPU's + 256MB PC2400 DDR memory + case + power supply ==> $445 + 2x$160 + $70 + case = $835 + case (reuse your existing disks) > Nice to hear it works (and works well, I assume) DAMN NICE !! I mean SWEET !! -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
In article <[EMAIL PROTECTED]>, Terry Lambert <[EMAIL PROTECTED]> wrote: > John Polstra wrote: > > I have had this on my to-do list for a long time, but I have no idea > > if or when it'll ever get implemented. It would require a focused > > period of working on it that I just don't have these days. Maybe if > > the economy gets worse ... [...] > I guess a better question would be whether funding would help? Sure -- that would take care of the "my real jobs take priority" problem. But I'm currently on two open-ended jobs, which is the most I can manage effectively. So right now I can't guess when I could do it even if I had funding. I'd very much like to do it, but I can't until I've met my existing commitments. John 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 ?
David O'Brien wrote: > > On Wed, Sep 05, 2001 at 09:33:55PM +0200, Thierry Herbelot wrote: > > "known-bad" revision for these babies -, and the 762 North Bridge of the > > soon to be there SMP Athlon) > > "Soon to be there"?? Hum... I'm typing to you from one. Excuse me : I meant for the common mortal, with prices more in line with what can be expected from Asus or Abit Nice to hear it works (and works well, I assume) TfH > > -- > -- David ([EMAIL PROTECTED]) -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[2]: auto relaying for subdomains -- why?
> On Wed, Sep 05, 2001 at 09:07:19PM +0800, Igor Podlesny wrote: >> >> My greetings! >> >> I noticed that some mailers (sendmail, postfix) in case they allow >> relayingforsomedomain.zonealsoallowrelayingfor >> subdomain-of.somedomain.zone. >> >> I can accept this as reasonable behavior but would like to know how to >> deny it! :) Also I wish to know what was the actual idea behind this? > Allow domain.com > disallow .domain.com Which software use this syntax? :) or just an idea? -- Igormailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re[2]: auto relaying for subdomains -- why?
poige> Yes, I saw this info here: poige> http://www.sendmail.org/m4/features.html#relay_mail_frombut most poige> valuable part of my question was about the purpose or the idea behind poige> this, cause it's not too clear to me why allowing relaying for domain poige> FOO.BAR should allow relaying for SUB.FOO.BAR? Because some places have only one machine (firewall) that accepts mail from the outside world for all of the hosts inside the network. For example, in my previous life as a sysadmin at WPI, only smtp.wpi.edu would accept incoming mail for all of the machines (> 3000) on campus. I'd much rather say "wpi.edu" in one place instead of listing loads of subdomains (ee.wpi.edu, me.wpi.edu, res.wpi.edu, ...). poige> I mentioned RFCs because I had a hope to find out the answer from it poige> but still haven't yet... RFC's cover protocols over the Internet, not local configuration or policy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[2]: auto relaying for subdomains -- why?
> Igor Podlesny wrote: >> I noticed that some mailers (sendmail, postfix) in case they allow >> relayingforsomedomain.zonealsoallowrelayingfor >> subdomain-of.somedomain.zone. >> >> I can accept this as reasonable behavior but would like to know how to >> deny it! :) Also I wish to know what was the actual idea behind this? > Sendmail does _not_ do this by default; you have to specifically > allow it by adding entries to your M4 file from which you build > your sendmail.cf. > If I had to guess, I'd guess that you enabled the domain via a > sendmail.cw file, Ieh :) But what is wrong with that? it just says to sendmail that he is the end point for mail destined to @foo.bar. Now it's named /etc/mail/local-host-names > rather than a virtusertable, or by setting > yourself up as a promiscuous relay. no... no for these gueses :) > -- Terry -- Igormailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[2]: auto relaying for subdomains -- why?
poige>> I noticed that some mailers (sendmail, postfix) in case they allow
poige>> relayingforsomedomain.zonealsoallowrelayingfor
poige>> subdomain-of.somedomain.zone.
poige>> I can accept this as reasonable behavior but would like to know how to
poige>> deny it! :) Also I wish to know what was the actual idea behind this?
>>From /usr/share/sendmail/cf/README:
> +--+
> | FEATURES |
> +--+
>
> Available features are:
>
> relay_hosts_only
> By default, names that are listed as RELAY in the access
> db and class {R} are domain names, not host names.
> For example, if you specify ``foo.com'', then mail to or
> from foo.com, abc.foo.com, or a.very.deep.domain.foo.com
> will all be accepted for relaying. This feature changes
> the behaviour to lookup individual host names only.
Yes, I saw this info here:
http://www.sendmail.org/m4/features.html#relay_mail_frombut most
valuable part of my question was about the purpose or the idea behind
this, cause it's not too clear to me why allowing relaying for domain
FOO.BAR should allow relaying for SUB.FOO.BAR? I mentioned RFCs
because I had a hope to find out the answer from it but still haven't
yet...
--
Igormailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
post 2.95.3 patches to test
Hi all, This patch has the "official" GCC 2.95 fixes for sjlj exceptions. As you may know, the ones we have in our tree are the sjlj changes that were in 2.95.3.test3, but removed for 2.95.3.test4. I would like to apply this patch to -current and then -stable afterwards. I have one good report, from a very good FreeBSD GCC tester. But before I commit it, I would not mind hearing any one else's experiences with it. Replying to the list so all can see is preferred. -- -- David ([EMAIL PROTECTED]) Index: ChangeLog === RCS file: /home/ncvs/src/contrib/gcc.295/ChangeLog,v retrieving revision 1.1.1.12 diff -u -r1.1.1.12 ChangeLog --- ChangeLog 2001/03/19 19:46:16 1.1.1.12 +++ ChangeLog 2001/08/30 21:05:19 @@ -1,3 +1,160 @@ +2001-08-29 David O'Brien <[EMAIL PROTECTED]> + + * config/alpha/crtbegin.asm: The normal calling convention for alpha is + to re-initialize gp using 'ldgp gp,0(ra)' after a jsr instruction. + +2001-06-19 Bernd Schmidt <[EMAIL PROTECTED]> + + * regmove.c (optimize_reg_copy_3): Do nothing if previous insn + carries a REG_EQUIV note. If it carries REG_EQUAL, delete the + note. + +2001-05-22 Bernd Schmidt <[EMAIL PROTECTED]> + + * sparc.md (movsf, movdf): Allow constant to integer reg moves. + (movsf, movdf splitters): Always split if there's an alignment + problem. + +2001-05-22 David Edelsohn <[EMAIL PROTECTED]> + + * rs6000.md (movsfcc,movdfcc): Remove NE case. + +2001-05-17 Bernd Schmidt <[EMAIL PROTECTED]> + + * function.c: Small formatting change to prevent compilation errors + on broken hpux systems. + + * expr.c (protect_from_queue): Protect against subsequent calls to + emit_queue. + (expand_expr, case ADDR_EXPR): Prevent protect_from_queue from being + too clever. + +2001-04-06 Bernd Schmidt <[EMAIL PROTECTED]> + + 2000-10-17 Franz Sirl <[EMAIL PROTECTED]> + * function.c (locate_and_pad_parm): Don't align stack unconditionally. + + Thu Oct 28 10:20:02 1999 Geoffrey Keating <[EMAIL PROTECTED]> + * config/rs6000/rs6000.md (movsf): Don't convert a SUBREG + of the function return register into a plain REG until + after function inlining is done. + +2001-04-04 Bernd Schmidt <[EMAIL PROTECTED]> + + Fri Nov 5 10:07:25 1999 Nick Clifton <[EMAIL PROTECTED]> + * function.c (is_addressof): New function. Returns true if + the given piece of RTL is an ADDRESSOF. + (purge_addressof_1): Make boolean. Return false if the + ADDRESSOFs could not be purged. + (purge_addressof): If ADDRESSOFs could not be purged from the + notes attached to an insn, remove the offending note(s), + unless they are attached to a libcall. + +2001-04-03 Bernd Schmidt <[EMAIL PROTECTED]> + + 2001-03-16 Jakub Jelinek <[EMAIL PROTECTED]> + * crtstuff.c (init_dummy): Use CRT_END_INIT_DUMMY if defined. + Remove ia32 linux PIC kludge and move it... + * config/i386/linux.h (CRT_END_INIT_DUMMY): ...here. + + * loop.c (combine_movables): Restrict combinations of constants with + different modes so that we don't introduce SUBREGs into memory + addresses. + + 2001-02-02 Philip Blundell <[EMAIL PROTECTED]> + * arm/linux-elf.h (MAKE_DECL_ONE_ONLY, UNIQUE_SECTION_P): Define. + (UNIQUE_SECTION): Define. + + Wed Aug 25 15:27:22 1999 Gavin Romig-Koch <[EMAIL PROTECTED]> + * combine.c (nonzero_bits) : Allow single-ly set registers to be + anywere in the function only if they are pseudos and set before + being used (not live at the start of the function). + (num_sign_bit_copies) : Same. + (get_last_value_validate) : Same. + (get_last_value) : Same. + + Fri Mar 3 12:49:28 2000 J"orn Rennecke <[EMAIL PROTECTED]> +* reload1.c (reload_combine_note_use): Handle return register USEs. + REG case: Handle multi-hard-register hard regs. + +2001-03-30 Bernd Schmidt <[EMAIL PROTECTED]> + + * jump.c (delete_barrier_successors): Fix error in last change. + + * reload1.c (delete_output_reload): Call eliminate_regs on substed. + (reload_as_needed): Call update_eliminable_offsets a bit later. + + * final.c (cleanup_subreg_operands): Also clean up inside MEMs. + + Mon Oct 4 02:31:20 1999 Mark Mitchell <[EMAIL PROTECTED]> + * mips.md: Define conditional move patterns for floating point + operands and DI mode conditions. + + 2000-11-25 Jakub Jelinek <[EMAIL PROTECTED]> + * config/sparc/sparc.md (muldi3_v8plus): Remove H constraint. + Handle CONST_INT as second argument. + +2001-03-28 Bernd Schmidt <[EMAIL PROTECTED]> + + * flow.c (propagate_block): When trying to delete a case vector, cope + if its label has LABEL_PRESERVE_P set. + * jump.c (j
Re: proposed change to pci_pci.c
I'd be OK with this being done as a hack for now. I think the bridge code needs to be a bit kinder about allowing "stupid" things to be done if they're set up by the BIOS. > I'd like to propose committing the following change which adds a new > undocumented option in the spirit of PCI_ENABLE_IO_MODES. The new option > (PCI_ALLOW_UNSUPPORTED_IO_RANGE) allows me to boot my old HP Omnibook > 4150 while docked. Since I've seen a couple other people need this fix, > I figure it would be more useful if they just had to add a line to their > kernel config instead of editing the source files. Any objections? > > -- Brooks > > Index: pci_pci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v > retrieving revision 1.3 > diff -u -r1.3 pci_pci.c > --- pci_pci.c 13 Dec 2000 01:25:11 - 1.3 > +++ pci_pci.c 7 Jun 2001 17:31:50 - > @@ -286,7 +286,9 @@ > " (decoding 0x%x-0x%x)\n", > device_get_name(child), device_get_unit(child), start, >end, > sc->iobase, sc->iolimit); > +#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE > return(NULL); > +#endif > } > if (bootverbose) > device_printf(sc->dev, "device %s%d requested decoded I/O range >0x%lx-0x= > %lx\n", > @@ -306,7 +308,9 @@ > " (decoding 0x%x-0x%x, 0x%x-0x%x)\n", > device_get_name(child), device_get_unit(child), start, >end, > sc->membase, sc->memlimit, sc->pmembase, sc->pmemlimit); > +#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE > return(NULL); > +#endif > } > if (bootverbose) > device_printf(sc->dev, "device %s%d requested decoded memory range >0x%lx= > -0x%lx\n", > > --=20 > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > > --ZGiS0Q5IWpPtfppv > Content-Type: application/pgp-signature > Content-Disposition: inline > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE7lsauXY6L6fI4GtQRAlYkAJ9BS8yO/HeRrVEmbp0HRZLy0VX/zQCfcwqI > 1TsAzTG5bFfK4NHTz7Kk+O8= > =Nu3h > -END PGP SIGNATURE- > > --ZGiS0Q5IWpPtfppv-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
proposed change to pci_pci.c
I'd like to propose committing the following change which adds a new undocumented option in the spirit of PCI_ENABLE_IO_MODES. The new option (PCI_ALLOW_UNSUPPORTED_IO_RANGE) allows me to boot my old HP Omnibook 4150 while docked. Since I've seen a couple other people need this fix, I figure it would be more useful if they just had to add a line to their kernel config instead of editing the source files. Any objections? -- Brooks Index: pci_pci.c === RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v retrieving revision 1.3 diff -u -r1.3 pci_pci.c --- pci_pci.c 13 Dec 2000 01:25:11 - 1.3 +++ pci_pci.c 7 Jun 2001 17:31:50 - @@ -286,7 +286,9 @@ " (decoding 0x%x-0x%x)\n", device_get_name(child), device_get_unit(child), start, end, sc->iobase, sc->iolimit); +#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE return(NULL); +#endif } if (bootverbose) device_printf(sc->dev, "device %s%d requested decoded I/O range 0x%lx-0x%lx\n", @@ -306,7 +308,9 @@ " (decoding 0x%x-0x%x, 0x%x-0x%x)\n", device_get_name(child), device_get_unit(child), start, end, sc->membase, sc->memlimit, sc->pmembase, sc->pmemlimit); +#ifndef PCI_ALLOW_UNSUPPORTED_IO_RANGE return(NULL); +#endif } if (bootverbose) device_printf(sc->dev, "device %s%d requested decoded memory range 0x%lx-0x%lx\n", -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: Tagged Command Queuing support for IC-35L0?0 ?
On Wed, Sep 05, 2001 at 09:33:55PM +0200, Thierry Herbelot wrote: > "known-bad" revision for these babies -, and the 762 North Bridge of the > soon to be there SMP Athlon) "Soon to be there"?? Hum... I'm typing to you from one. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Posix Threading
[ I really hate it when my window manager gets stuck in a loop spinning while I'm composing a mail message and I forget to fix up the mail message. *sigh* ] > On 05-Sep-01 Terry Lambert wrote: >> [EMAIL PROTECTED] wrote: >>> >>> Hi All, >>> I am trying to create threads under HP-UX 11 using POSIX threads library >>> and >>> using the method pthread_create(...). >>> >>> But I don't know how can I create a thread in a suspended state. >> >> First the obligatory "off topic" humor: >> >> This is not the place to ask about HP-UX programming; you >> probably want the Hewlet-Compaqard user's mailing list... 8-p. >> >> -- >> >> If the intent is to have "a pool of idle threads", ready to >> go when you get request traffic, and get around the latency, >> well, you'd do a lot better in the latency department if you >> went to a finite state automaton, instead of messing with >> threads. But if you insist, the best you are going to be >> able to get is use of a mutex, since a condition variable will >> result in a "thundering herd" problem. You will still have to >> eat the latency for the mutex trigger to the thread you give >> the work to, however (this is how I designed the work-to-do >> dispatcher in the Pathworks for VMS (NetWare) product for DEC >> and Novell). Most of what you say is ok, but this is wrong. condition variables do not mandate using a wakeup all strategy. There is such a thing as 'signal' instead of 'broadcast', which only wakes up one thread. PTHREAD_COND_SIGNAL(3) FreeBSD Library Functions Manual PTHREAD_COND_SIGNAL(3) SYNOPSIS #include int pthread_cond_signal(pthread_cond_t *cond); DESCRIPTION The pthread_cond_signal() function unblocks one thread waiting for the condition variable cond. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Posix Threading
On 05-Sep-01 Terry Lambert wrote:
> [EMAIL PROTECTED] wrote:
>>
>> Hi All,
>> I am trying to create threads under HP-UX 11 using POSIX threads library
>> and
>> using the method pthread_create(...).
>>
>> But I don't know how can I create a thread in a suspended state.
>
> First the obligatory "off topic" humor:
>
> This is not the place to ask about HP-UX programming; you
> probably want the Hewlet-Compaqard user's mailing list... 8-p.
>
> --
>
> You don't give us enough information about your application
> for us to tell you the correct approach to building it; you've
> started with a hammer ("initially suspended threads") and are
> ignoring other tools (e.g. "the jaws of life") in your search
> for a way to instance your hammer, under the theory that your
> problem is a nail (it might not be; you've given us no way to
> know).
>
> Probably switching to FreeBSD and the kqueue interface would
> better match your problem.
>
>
> Let's do some setup, and then guess at what you wanted to do,
> and give you several approaches to our satisfying our guesses...
>
>
> Short answer: You can't. The "suspended" state is an attribute
> of the thread that is controlled by the threads scheduler, and
> is not directly controllable by you.
>
>
> A thread is guaranteed to be suspended only when it is waiting
> on a mutex, condition variable, or blocking call (such as I/O).
>
> I suggest you rethink your design.
>
>
> If the intent is to get an immediate context switch back to
> yourself, you will need to create a mutex that can not be
> acquired by the newly created thread, and attempt to acquire
> it as the first thing you do.
>
> You can then immediately release it so as not to block other
> threads trying the same dirty trick. Note that there is not
> an explicit "yield", so you will have to do something like
> this to get a "yield" equivalent.
>
>
> Alternately, if the intent is to create threads so that they
> will be around when you need them, you would be better off
> delaying their creation until you need them. The expensive
> part of threads creation is _supposed_ to be the allocation
> of the stack; so if you keep a pool of preallocated stacks
> lying around for your use, you will get only a small startup
> latency.
>
> If the intent is to have "a pool of idle threads", ready to
> go when you get request traffic, and get around the latency,
> well, you'd do a lot better in the latency department if you
> went to a finite state automaton, instead of messing with
> threads. But if you insist, the best you are going to be
> able to get is use of a mutex, since a condition variable will
> result in a "thundering herd" problem. You will still have to
> eat the latency for the mutex trigger to the thread you give
> the work to, however (this is how I designed the work-to-do
> dispatcher in the Pathworks for VMS (NetWare) product for DEC
> and Novell).
>
> If the intent is a "horse race", where you create a bunch of
> threads, and then open the "starting gate" and have them all
> start going ``at once'', then you want a condition variable. I
> intentionally quoted ``at once'', since the concurrency will
> not be real without multiple CPUs and cooperation from the OS,
> it will be virtual -- just as if you were running multiple
> processes, instead of trying to use threads. This is an
> artifact of the scheduler, and varies from implementation to
> implementation.
>
> Note: I don't know what level of standards compliance the
> HP-UX 11 version of pthreads has achieved; some of the things
> described above are probably not going to be easy to achieve
> in downrev versions of the library. Last time I looked, the
> HP-UX version of pthreads was a Draft-4 version, not a Draft-10
> or standard version, so you may be in more trouble than you
> originally thought; specifically, you will have a problem with
> creating a preinitialized mutex in a Draft-4 version of pthreads,
> so you will have to create the mutex (if you use one) first.
>
> -- Terry
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
In message <[EMAIL PROTECTED]> Julian Elischer writes: : As a workaround, people could just gat the source each week : and do an cvs import into the vendor branch via script.. : (of course with doing it correctly you could have matching version numbers : on the vendor branch) As someone who does lots of vendor branch imports of FreeBSD into cvs, I can tell you that automating it is fraught with dangers if you have any significant changes in your base tree. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
In message <[EMAIL PROTECTED]> Terry Lambert writes: : Yes, precisely. People always complain that companies are : gun-shy of -current; the inability to tag a "sufficiently : stable" version is why most companies stay away from it. For what its worth, I did most of the pccard based work in -current, then switched to -stable for testing/deploying it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel ddb help
Your snapshot is cool and I have found your old mail regarding VMWARE. One more question: Is X-windows needed for this stuff? Thanks, -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
As a workaround, people could just gat the source each week and do an cvs import into the vendor branch via script.. (of course with doing it correctly you could have matching version numbers on the vendor branch) On Wed, 5 Sep 2001, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Nate Williams <[EMAIL PROTECTED]> wrote: > > > > > > Any chance of getting CVSup to transfer from a remote repository > > > to a local vendor branch, instead of from a remote repository to > > > a local repository? > > > > The problem is that you aren't just transferring bits from the HEAD, but > > from multiple active branches. As John already stated, CVS doesn't > > handle multiple 'vendor' branches well (and in this case, the FreeBSD > > tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, > > RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) > > > > CVS is simply not setup to do what you ask. :( > > No, Terry's idea is sound as long as you only try to track one branch > of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do > a checkout-mode type of fetch from a branch of the FreeBSD repository > and directly import it onto your own vendor branch. This would meet > the needs of a lot of people, e.g., companies who make products based > on FreeBSD. > > I have had this on my to-do list for a long time, but I have no idea > if or when it'll ever get implemented. It would require a focused > period of working on it that I just don't have these days. Maybe if > the economy gets worse ... > > John > -- > John Polstra [EMAIL PROTECTED] > John D. Polstra & Co., Inc.Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > > 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: kernel ddb/gdb help
On Wed, 5 Sep 2001, Zhihui Zhang wrote: > > > On Wed, 5 Sep 2001, Julian Elischer wrote: > > > > WHen I have one machine I usually debug by running the new kernel > > within a VMWARE virtual machine. Using the nmdm driver > > you can run gdb in the main machine to debug it, all within one machine. > > (unfortunatly it doesn't help for debugging drivers because the virtual > > machine doesn't have acces to the real hardware). > > I am interested in setting up this environment. Is there any help > information out there? If not, can you give me a few guideline? I will try > myself. > first you need to get vmware running on your machine. (use the vmware2 port) (I select host-only (non bridged) networking) then you boot and install FreeBSD on the machine. then in the virtual machine, set in the file /boot/device.hints the line: hints.sio.1.flags="0xc0" in the vmware config editor set com2 to type "device" and give it a device of /dev/nmdm0A then in the gdb config follow the instructions for remote debugging but use the device nmdm0B when the virtual machine enters the debugger (ddb) enter the word "gdb" to make it use the gdb stub then you will need to do a 's' to make it actually switch. In teh compile directory of the kernel on the main machine: enter gdb and set remote debugging mode. (I use the folloing .gdbinit file in the compile directory:) file kernel.debug set remotebaud 9600 target remote /dev/nmdmb1 It's also useful to set a serial console on com1 of the virtual machine so tha tyou can record and capture messages. I sent a message outlining how to do all this to: [EMAIL PROTECTED] on Fri, 19 Jan 2001 Message ID: <[EMAIL PROTECTED]> if you want to look at it in the archives. also there is a screenshot that probably has some hints on it at http://www.freebsd.org/~julian/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
John Polstra wrote: > No, Terry's idea is sound as long as you only try to track one branch > of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do > a checkout-mode type of fetch from a branch of the FreeBSD repository > and directly import it onto your own vendor branch. This would meet > the needs of a lot of people, e.g., companies who make products based > on FreeBSD. Yes, precisely. People always complain that companies are gun-shy of -current; the inability to tag a "sufficiently stable" version is why most companies stay away from it. This means that most commercially funded work occurs on the -RELEASE/-STABLE branches, for fear of destabilizing their products. Everyone in FreeBSD-land always complains about this, even as they continue to make -current even less stable, and less likely to result in them getting funded help to work on it. So a lot of forward looking research takes a lot longer than it should to bear fruit (or wither, if it turns out to be a net loss). > I have had this on my to-do list for a long time, but I have no idea > if or when it'll ever get implemented. It would require a focused > period of working on it that I just don't have these days. Maybe if > the economy gets worse ... I hear Hewlett-Compaqard is laying off 15,000, if that's any incentive... I guess a better question would be whether funding would help? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
Nate Williams wrote: > > I guess I'll ask the usual question: > > > > Any chance of getting CVSup to transfer from a remote repository > > to a local vendor branch, instead of from a remote repository to > > a local repository? > > The problem is that you aren't just transferring bits from the HEAD, but > from multiple active branches. As John already stated, CVS doesn't > handle multiple 'vendor' branches well (and in this case, the FreeBSD > tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, > RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) > > CVS is simply not setup to do what you ask. :( I know how to make it do it, using a numeric tuple pair prefix to effectively force things onto a vendor branch; CVS will just "do the right thing" with the data: it's really CVSup, not CVS, which is the bottleneck. I've actually done this one on an experimental basis, by using CVSup to mirror the CVS repository, and then using scripts to hack the holy heck out of the mirror during a copy, which left me with a local repository containing only a skeleton and a vendor branch (with ID's up in the 5000's). It worked, but I got a cramp: the local copy was so expensive compared to an integrated approach, that it was not worth maintaining. It's just been 15 years or so since I did any Modula programming, and the Modula 3 compiler is a behemoth that I'd rather not have to slay to get real work done. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Posix Threading
[EMAIL PROTECTED] wrote:
>
> Hi All,
> I am trying to create threads under HP-UX 11 using POSIX threads library and
> using the method pthread_create(...).
>
> But I don't know how can I create a thread in a suspended state.
First the obligatory "off topic" humor:
This is not the place to ask about HP-UX programming; you
probably want the Hewlet-Compaqard user's mailing list... 8-p.
--
You don't give us enough information about your application
for us to tell you the correct approach to building it; you've
started with a hammer ("initially suspended threads") and are
ignoring other tools (e.g. "the jaws of life") in your search
for a way to instance your hammer, under the theory that your
problem is a nail (it might not be; you've given us no way to
know).
Probably switching to FreeBSD and the kqueue interface would
better match your problem.
Let's do some setup, and then guess at what you wanted to do,
and give you several approaches to our satisfying our guesses...
Short answer: You can't. The "suspended" state is an attribute
of the thread that is controlled by the threads scheduler, and
is not directly controllable by you.
A thread is guaranteed to be suspended only when it is waiting
on a mutex, condition variable, or blocking call (such as I/O).
I suggest you rethink your design.
If the intent is to get an immediate context switch back to
yourself, you will need to create a mutex that can not be
acquired by the newly created thread, and attempt to acquire
it as the first thing you do.
You can then immediately release it so as not to block other
threads trying the same dirty trick. Note that there is not
an explicit "yield", so you will have to do something like
this to get a "yield" equivalent.
Alternately, if the intent is to create threads so that they
will be around when you need them, you would be better off
delaying their creation until you need them. The expensive
part of threads creation is _supposed_ to be the allocation
of the stack; so if you keep a pool of preallocated stacks
lying around for your use, you will get only a small startup
latency.
If the intent is to have "a pool of idle threads", ready to
go when you get request traffic, and get around the latency,
well, you'd do a lot better in the latency department if you
went to a finite state automaton, instead of messing with
threads. But if you insist, the best you are going to be
able to get is use of a mutex, since a condition variable will
result in a "thundering herd" problem. You will still have to
eat the latency for the mutex trigger to the thread you give
the work to, however (this is how I designed the work-to-do
dispatcher in the Pathworks for VMS (NetWare) product for DEC
and Novell).
If the intent is a "horse race", where you create a bunch of
threads, and then open the "starting gate" and have them all
start going ``at once'', then you want a condition variable. I
intentionally quoted ``at once'', since the concurrency will
not be real without multiple CPUs and cooperation from the OS,
it will be virtual -- just as if you were running multiple
processes, instead of trying to use threads. This is an
artifact of the scheduler, and varies from implementation to
implementation.
Note: I don't know what level of standards compliance the
HP-UX 11 version of pthreads has achieved; some of the things
described above are probably not going to be easy to achieve
in downrev versions of the library. Last time I looked, the
HP-UX version of pthreads was a Draft-4 version, not a Draft-10
or standard version, so you may be in more trouble than you
originally thought; specifically, you will have a problem with
creating a preinitialized mutex in a Draft-4 version of pthreads,
so you will have to create the mutex (if you use one) first.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
In article <[EMAIL PROTECTED]>, Nate Williams <[EMAIL PROTECTED]> wrote: > So, you're saying that the person would choose the branch (which may > be RELENG_4 *OR* HEAD). Yep. For instance, a company might have a product that's based on RELENG_4, but with some local mods. So FreeBSD-4.x is in effect that company's "vendor". > I can see how that would work for RELENG_4, but for the HEAD, many > of the files on the HEAD in /usr/src/contrib are on vendor branches, > which means it would be a *nightmare* to get that right (IMO). It would still work just the same. You're just checking out -current and importing it onto your own vendor branch. You don't know or care about FreeBSD's vendor branch. Of course (and this is one of the big complications), CVSup would have to map the version numbers somehow. Another big complication would be that at some point in the future a user would want to switch from being based on RELENG_4 to being based on RELENG_5. I have a feeling that could get tricky for CVSup to deal with. > Although, it may not be as useful to developers, who often have > to track development in multiple branches (for MFC's). Right, it would be pretty worthless for FreeBSD developers. > > Maybe if the economy gets worse ... > > *sigh* Let's hope it doesn't come down to that. Just looking for that silver lining. Mom would be so proud of me. :-) John 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 ?
Hello, sos "Søren Schmidt" wrote: > [SNIP] > Anyhow, the problem at hand is more like bad chipsets, there is ALOT > of ATA chipsets thats not working right when used the way needed for > tagged queuing. That said, the IBM DTLA's series of drives are extremely is there some place where a "recommended" list of chipsets is compiled ? (my interest would be about oldies like 440LX/400BX - there may be some "known-bad" revision for these babies -, and the 762 North Bridge of the soon to be there SMP Athlon) Cheers (and keep up the ata) -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
> > > Any chance of getting CVSup to transfer from a remote repository > > > to a local vendor branch, instead of from a remote repository to > > > a local repository? > > > > The problem is that you aren't just transferring bits from the HEAD, but > > from multiple active branches. As John already stated, CVS doesn't > > handle multiple 'vendor' branches well (and in this case, the FreeBSD > > tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, > > RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) > > > > CVS is simply not setup to do what you ask. :( > > No, Terry's idea is sound as long as you only try to track one branch > of FreeBSD. So, you're saying that the person would choose the branch (which may be RELENG_4 *OR* HEAD). I can see how that would work for RELENG_4, but for the HEAD, many of the files on the HEAD in /usr/src/contrib are on vendor branches, which means it would be a *nightmare* to get that right (IMO). > I.e., you consider FreeBSD to be your vendor, and you do > a checkout-mode type of fetch from a branch of the FreeBSD repository > and directly import it onto your own vendor branch. This would meet > the needs of a lot of people, e.g., companies who make products based > on FreeBSD. Agreed. Although, it may not be as useful to developers, who often have to track development in multiple branches (for MFC's). > I have had this on my to-do list for a long time, but I have no idea > if or when it'll ever get implemented. It would require a focused > period of working on it that I just don't have these days. Maybe if > the economy gets worse ... *sigh* Let's hope it doesn't come down to that. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
In article <[EMAIL PROTECTED]>, Nate Williams <[EMAIL PROTECTED]> wrote: > > > > Any chance of getting CVSup to transfer from a remote repository > > to a local vendor branch, instead of from a remote repository to > > a local repository? > > The problem is that you aren't just transferring bits from the HEAD, but > from multiple active branches. As John already stated, CVS doesn't > handle multiple 'vendor' branches well (and in this case, the FreeBSD > tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, > RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) > > CVS is simply not setup to do what you ask. :( No, Terry's idea is sound as long as you only try to track one branch of FreeBSD. I.e., you consider FreeBSD to be your vendor, and you do a checkout-mode type of fetch from a branch of the FreeBSD repository and directly import it onto your own vendor branch. This would meet the needs of a lot of people, e.g., companies who make products based on FreeBSD. I have had this on my to-do list for a long time, but I have no idea if or when it'll ever get implemented. It would require a focused period of working on it that I just don't have these days. Maybe if the economy gets worse ... John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel ddb help
On Wed, 5 Sep 2001, Julian Elischer wrote: > you can gdb -k mykernel /dev/mem > and do > list bqrelse+0x25 > (I think) > alternatively, > in ddb you can do: > > > x/iii bqrelse > > and work out what is wrong by reading the machine instructions > > > WHen I have one machine I usually debug by running the new kernel > within a VMWARE virtual machine. Using the nmdm driver > you can run gdb in the main machine to debug it, all within one machine. > (unfortunatly it doesn't help for debugging drivers because the virtual > machine doesn't have acces to the real hardware). I am interested in setting up this environment. Is there any help information out there? If not, can you give me a few guideline? I will try myself. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
> > CVS claims to support multiple vendor branches, but in practice it > > doesn't work in any useful sense. There's at least one place in the > > CVS sources where "the" vendor branch is hard-coded as 1.1.1. You > > really don't want to use multiple vendor branches -- trust me. :-) > > Use two repositories instead, or use perforce. > > I guess I'll ask the usual question: > > Any chance of getting CVSup to transfer from a remote repository > to a local vendor branch, instead of from a remote repository to > a local repository? The problem is that you aren't just transferring bits from the HEAD, but from multiple active branches. As John already stated, CVS doesn't handle multiple 'vendor' branches well (and in this case, the FreeBSD tree has vendor (CSRG) branches, FreeBSD vendor branches (RELENG_2, RELENG_3, ..., contrib vendor branches (TCSH, GCC, etc..) CVS is simply not setup to do what you ask. :( Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel ddb help
you can gdb -k mykernel /dev/mem and do list bqrelse+0x25 (I think) alternatively, in ddb you can do: x/iii bqrelse and work out what is wrong by reading the machine instructions WHen I have one machine I usually debug by running the new kernel within a VMWARE virtual machine. Using the nmdm driver you can run gdb in the main machine to debug it, all within one machine. (unfortunatly it doesn't help for debugging drivers because the virtual machine doesn't have acces to the real hardware). On Wed, 5 Sep 2001, Zhihui Zhang wrote: > > I know gdb can source stepping the kernel. But without two machines, you > can not do it. Now I have only one machine and the system panic: > > db> trace > bqrelse(cxxx, cxxx, cxxx, c, cxxx) at bqrelse+0x25 > > is there a way to use these addresses to figure out which line or lines of > source are suspect to cause the panic? Thanks. > > Regards, > > -Zhihui > > > 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: local changes to CVS tree
John Polstra wrote: > CVS claims to support multiple vendor branches, but in practice it > doesn't work in any useful sense. There's at least one place in the > CVS sources where "the" vendor branch is hard-coded as 1.1.1. You > really don't want to use multiple vendor branches -- trust me. :-) > Use two repositories instead, or use perforce. I guess I'll ask the usual question: Any chance of getting CVSup to transfer from a remote repository to a local vendor branch, instead of from a remote repository to a local repository? This would be incredibly useful for building a combined local source tree from multiple project's CVS repositories. It could be used by FreeBSD for a number of "contrib" things, as well... Just a "hint hint" to the Modula 3 programmers among us... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: auto relaying for subdomains -- why?
Igor Podlesny wrote: > I noticed that some mailers (sendmail, postfix) in case they allow > relayingforsomedomain.zonealsoallowrelayingfor > subdomain-of.somedomain.zone. > > I can accept this as reasonable behavior but would like to know how to > deny it! :) Also I wish to know what was the actual idea behind this? Sendmail does _not_ do this by default; you have to specifically allow it by adding entries to your M4 file from which you build your sendmail.cf. If I had to guess, I'd guess that you enabled the domain via a sendmail.cw file, rather than a virtusertable, or by setting yourself up as a promiscuous relay. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: kernel ddb help
You can use gdb on the dump file or even on live kernel after reboot to figure out exactly what the problem was. Use gdb -k ./kernel.debug /dev/mem or gdb -k ./kernel.debug /var/crash/vmcore. On 05-Sep-2001 Zhihui Zhang wrote: > > I know gdb can source stepping the kernel. But without two machines, you > can not do it. Now I have only one machine and the system panic: > > db> trace > bqrelse(cxxx, cxxx, cxxx, c, cxxx) at bqrelse+0x25 > > is there a way to use these addresses to figure out which line or lines of > source are suspect to cause the panic? Thanks. E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]> Date: 05-Sep-2001 Time: 14:44:40 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing Performance?
On Wed, Sep 05, 2001 at 12:19:27PM +0200, Attila Nagy wrote: > Hello, > > > The last is a dual processor alpha board. Alpha motherboards have > > generally better memory IO, including 2.6 Gb/Sec to main memory. > > Unfortunately it can only take 2 gig of RAM. > AFAIK, that's not a problem, because FreeBSD on alpha can't handle more > than that... Correct. I noticed that NetBSD appears to have fixed this BTW. -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kernel ddb help
I know gdb can source stepping the kernel. But without two machines, you can not do it. Now I have only one machine and the system panic: db> trace bqrelse(cxxx, cxxx, cxxx, c, cxxx) at bqrelse+0x25 is there a way to use these addresses to figure out which line or lines of source are suspect to cause the panic? Thanks. Regards, -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
usr.sbin/ac change - request for comments
The code of usr.sbin/ac/ includes support for handling ":0.0" as
console logins, when CONSOLE_TTY is defined during compilation.
Looking at the code, and revisions from 1.2 and up, this doesn't seem
to be used. Is there any reason why this should not be removed from
the sources. It's not used anyway :/
I'm talking about pieces of code like the following:
#ifdef CONSOLE_TTY
static char *Console = CONSOLE_TTY;
#endif
or parts like the even more exotic:
while ((c = getopt(argc, argv, "Dc:dpt:w:")) != -1) {
switch (c) {
...
case 'c':
#ifdef CONSOLE_TTY
Console = optarg;
#else
usage();/* XXX */
#endif
break;
The code is cluttered all over with #ifdef'ed pieces of code that are
not used. Is it really necessary that we keep these parts?
-giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
In article <[EMAIL PROTECTED]>, Peter Pentchev <[EMAIL PROTECTED]> wrote: > > Also, I'm not really sure if CVS would allow having two vendor branches > (say, RELENG_4 and RELENG_5) and two corresponding working branches > (your changes to RELENG_4 and your changes to RELENG_5, which might be > *way* different). CVS claims to support multiple vendor branches, but in practice it doesn't work in any useful sense. There's at least one place in the CVS sources where "the" vendor branch is hard-coded as 1.1.1. You really don't want to use multiple vendor branches -- trust me. :-) Use two repositories instead, or use perforce. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RES: no memory for rx list
I think that´s the problem 1598/1616/4096 mbufs in use (current/peak/max): 1107 mbufs allocated to data 491 mbufs allocated to packet headers 1024/1024/1024 mbuf clusters in use (current/peak/max) 2452 Kbytes allocated to network (79% of mb_map in use) 8784 requests for memory denied I´ll look for tunning... -Mensagem original- De: Nicolai Petri [mailto:[EMAIL PROTECTED]] Enviada em: quarta-feira, 5 de setembro de 2001 12:50 Para: Daniel Abad Cc: [EMAIL PROTECTED] Assunto: Re: no memory for rx list Hi Daniel, Check netstat -m to see if your are out of mbufs (my guess) To fix this see the man page for 'tuning' It describes how to increase the network buffers on your system. Best regards, --- Nicolai Petri - Original Message - From: "Daniel Abad" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 05, 2001 5:40 PM Subject: no memory for rx list > Help!!! What can I do??? > > /var/log/messages: > Sep 5 09:49:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:49:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:51:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:52:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:57:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:58:00 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:58:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:58:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:59:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:59:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 10:04:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 10:04:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > /var/log/httpd/error_log: > [Wed Sep 5 10:49:36 2001] [notice] Apache/1.3.20 (Unix) PHP/3.0.18 > configured -- resuming normal operations > [Wed Sep 5 10:49:36 2001] [info] Server built: Sep 4 2001 01:49:08 > [Wed Sep 5 10:50:12 2001] [error] server reached MaxClients setting, > consider raising the MaxClients setting > > /usr/local/apache/conf/httpd.conf > MinSpareServers 200 > MaxSpareServers 1 > StartServers 1024 > MaxClients 256 > MaxRequestsPerChild 1 > > > Tks, > > Dan > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message Daniel Abad.vcf
Re: auto relaying for subdomains -- why?
poige> I noticed that some mailers (sendmail, postfix) in case they allow
poige> relayingforsomedomain.zonealsoallowrelayingfor
poige> subdomain-of.somedomain.zone.
poige> I can accept this as reasonable behavior but would like to know how to
poige> deny it! :) Also I wish to know what was the actual idea behind this?
From /usr/share/sendmail/cf/README:
+--+
| FEATURES |
+--+
...
Available features are:
...
relay_hosts_only
By default, names that are listed as RELAY in the access
db and class {R} are domain names, not host names.
For example, if you specify ``foo.com'', then mail to or
from foo.com, abc.foo.com, or a.very.deep.domain.foo.com
will all be accepted for relaying. This feature changes
the behaviour to lookup individual host names only.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: no memory for rx list
Hi Daniel, Check netstat -m to see if your are out of mbufs (my guess) To fix this see the man page for 'tuning' It describes how to increase the network buffers on your system. Best regards, --- Nicolai Petri - Original Message - From: "Daniel Abad" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 05, 2001 5:40 PM Subject: no memory for rx list > Help!!! What can I do??? > > /var/log/messages: > Sep 5 09:49:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:49:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:51:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:52:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:57:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:58:00 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:58:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:58:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:59:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 09:59:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 10:04:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > Sep 5 10:04:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet > dropped! > /var/log/httpd/error_log: > [Wed Sep 5 10:49:36 2001] [notice] Apache/1.3.20 (Unix) PHP/3.0.18 > configured -- resuming normal operations > [Wed Sep 5 10:49:36 2001] [info] Server built: Sep 4 2001 01:49:08 > [Wed Sep 5 10:50:12 2001] [error] server reached MaxClients setting, > consider raising the MaxClients setting > > /usr/local/apache/conf/httpd.conf > MinSpareServers 200 > MaxSpareServers 1 > StartServers 1024 > MaxClients 256 > MaxRequestsPerChild 1 > > > Tks, > > Dan > > 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
no memory for rx list
Help!!! What can I do??? /var/log/messages: Sep 5 09:49:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:49:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:51:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:52:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:57:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:58:00 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:58:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:58:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:59:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 09:59:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 10:04:26 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! Sep 5 10:04:56 Brparcunix02 /kernel: xl0: no memory for rx list -- packet dropped! /var/log/httpd/error_log: [Wed Sep 5 10:49:36 2001] [notice] Apache/1.3.20 (Unix) PHP/3.0.18 configured -- resuming normal operations [Wed Sep 5 10:49:36 2001] [info] Server built: Sep 4 2001 01:49:08 [Wed Sep 5 10:50:12 2001] [error] server reached MaxClients setting, consider raising the MaxClients setting /usr/local/apache/conf/httpd.conf MinSpareServers 200 MaxSpareServers 1 StartServers 1024 MaxClients 256 MaxRequestsPerChild 1 Tks, Dan 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
While on the subject of VFS locking... Accessing devfs through a nullfs redirection causes a panic() due to locking issues. I haven't had time to look at this in detail yet, if somebody wants to jump up and fix the problem, feel free... -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Posix Threading
On Wed, Sep 05, 2001 at 04:18:19PM +0100, [EMAIL PROTECTED] wrote: > > > Hi All, > I am trying to create threads under HP-UX 11 using POSIX threads library and > using the method pthread_create(...). > > But I don't know how can I create a thread in a suspended state. > > Thanks in advance This mailing list is a forum for discussion related to the development of the FreeBSD operating system, so it probably isn't the best place to ask HP-UX specific questions. -- garrett rooney Unix was not designed to stop you from [EMAIL PROTECTED] doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Posix Threading
Hi All, I am trying to create threads under HP-UX 11 using POSIX threads library and using the method pthread_create(...). But I don't know how can I create a thread in a suspended state. Thanks in advance Ullasan --- This email message (including any attachment) is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the addressee, you may not disclose it, copy it, distribute it or take or omit to take any action on foot of it. Any such act or omission is prohibited and may be unlawful. This message (including any attachment) is transmitted for discussion purposes only. It is protected by copyright laws and it has no other legal or contractual standing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
On Wed, Sep 05, 2001 at 01:10:27PM +0200, Alexander Langer wrote: > Thus spake Kris Kennaway ([EMAIL PROTECTED]): > > > On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: > > > > > I have it fixed now in my local CVS tree. Hopefully Kris will commit > > > something to fix it soon :-) > > I'm just curious: > How do people fix stuff in their local CVS tree and sync other > FreeBSD changes with that? > > I mean I have much stuff, which gets > M file > in the next cvs update, but I'd really like to cvs commit them > to my local /home/ncvs, but cvsup will overwrite these changes. One way that (I think it was) Sheldon pointed out to me a few months ago would be keeping your own CVS repository and vendor-importing the FreeBSD source on a regular basis. The regular vendor-import is quite time-consuming though :( Also, I'm not really sure if CVS would allow having two vendor branches (say, RELENG_4 and RELENG_5) and two corresponding working branches (your changes to RELENG_4 and your changes to RELENG_5, which might be *way* different). G'luck, Peter -- Thit sentence is not self-referential because "thit" is not a word. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: auto relaying for subdomains -- why?
On Wed, Sep 05, 2001 at 09:07:19PM +0800, Igor Podlesny wrote: > > My greetings! > > I noticed that some mailers (sendmail, postfix) in case they allow > relayingforsomedomain.zonealsoallowrelayingfor > subdomain-of.somedomain.zone. > > I can accept this as reasonable behavior but would like to know how to > deny it! :) Also I wish to know what was the actual idea behind this? Allow domain.com disallow .domain.com -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
On Wed, Sep 05, 2001 at 01:10:27PM +0200, Alexander Langer wrote: > Thus spake Kris Kennaway ([EMAIL PROTECTED]): > > > On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: > > > > > I have it fixed now in my local CVS tree. Hopefully Kris will commit > > > something to fix it soon :-) > > I'm just curious: > How do people fix stuff in their local CVS tree and sync other > FreeBSD changes with that? It's a CVSup FAQ: http://www.polstra.com/projects/freeware/CVSup/faq.html#canilocal -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: local changes to CVS tree
Thus spake Peter Pentchev ([EMAIL PROTECTED]): > One way that (I think it was) Sheldon pointed out to me a few months > ago would be keeping your own CVS repository and vendor-importing > the FreeBSD source on a regular basis. The regular vendor-import > is quite time-consuming though :( That sucks. >From what I've heart about the Sparc64 development on freefall, perforce seems to be able to do such stuff automatically, right? Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
auto relaying for subdomains -- why?
My greetings! I noticed that some mailers (sendmail, postfix) in case they allow relayingforsomedomain.zonealsoallowrelayingfor subdomain-of.somedomain.zone. I can accept this as reasonable behavior but would like to know how to deny it! :) Also I wish to know what was the actual idea behind this? P.S. I searched for answers through Inet, digging RFCs but nothing have found yet... -- Best regards, Igor mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SLOW ftp transfers one way
you should check the settings of your switch ports and look into the output of 'ifconfig -a'. try nailing the switch to 100baseTX.full duplex and set up the network card with 'ifconfig fxp0 media 100baseTX mediaopt full-duplex' this solves carrier transition problems with stupid switch hardware which cause throughtput degradation. in the environments i administer, nway autonegotiation is always turned off, both sides are set to 100base/fdup. /k Hans Christensen([EMAIL PROTECTED])@2001.08.30 20:43:38 +: > I have recently redefined a problem which has been plaguing me for close > to a year now. I have several FBSD boxes at a site fed by a Sprint T1 (Site > A). Each of these boxes is capable of ftp'ing to each other on the same > subnet at speeds approaching the limits of the disk subsystem. In short, > transfers on the LAN between FBSD boxen appear to be fine. In addition, I > have enlisted the help of the folks at sprint to ftp in and out of these > boxes with speeds approaching the limits of the T1 line - no problem there. > It should be noted that the sprint guys have done their transfers from > within sprint's network and are therefore NOT crossing their own network > access points. > Here is where it gets weird. If I ftp into one of my boxes at Site A > across the WAN (in this case from a colocation facility) and put a large > file onto my server in Site A, I get speeds of about 10KB/s. This may > fluctuate from 4KB/s to 16KB/s, but it far below what one would normally see > across a T1 line. Interestingly enough, sending ftp traffic out of Site A > seems to move five to ten time faster - not perfect, but workable. Below are > example of the same file transferred first out of Site A to the colocation > facility, and then the same file just transferred, back into Site A. You > will note the difference in speeds... This colocation facility is NOT on the > same network as sprint and therefore DOES have to cross one of Sprint's > network access points. Furthermore, to rule out the possibility that the > colo facility is to blame, I ftp'ed from a linux box on yet another ISP's > network. This linux box had the same type of performance problems. Slow puts > to Site A and reasonable gets from Site A. > I have seen this before as well, between boxes at the colocation > facility and again across different class c subnets. Sprint claims that the > problem lies with the MTU settings of the boxes at the "linux side" and the > "colo side." This smells wrong to me, but I confess that I don't really know > that it is wrong. I have looked in the FBSD bug reports for any indication > of a similar problem and do not see any so far, but I have seen several > questions on the mailing list archives. Most of these are dismissed as > improper configuration of ethernet cards. I have tried these suggestions but > found no relief. > I ftp close to a GB of info every night into Site A and I need it to go > faster than it has been going, but I'm stumped. Anybody got any clues for > the clueless? > > Hans Christensen > [EMAIL PROTECTED] > > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> put jdk-1_2_2_006-win.exe > local: jdk-1_2_2_006-win.exe remote: jdk-1_2_2_006-win.exe > 227 Entering Passive Mode (). > 150 Opening BINARY mode data connection for jdk-1_2_2_006-win.exe > 100% > |*** > ***| 298 KB00:00 ETA > 226 Transfer complete. > 305152 bytes sent in 3.66 seconds (81.33 KB/s) > ftp> get jdk-1_2_2_006-win.exe > local: jdk-1_2_2_006-win.exe remote: jdk-1_2_2_006-win.exe > 227 Entering Passive Mode (*). > 150 Opening BINARY mode data connection for jdk-1_2_2_006-win.exe (305152 > bytes). > 100% > |*** > ***| 298 KB00:00 ETA > 226 Transfer complete. > 305152 bytes received in 25.77 seconds (11.56 KB/s) > ftp> > > > Here is a dmesg: > > Copyright (c) 1992-2001 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 4.3-STABLE #0: Fri Jun 1 06:59:28 PDT 2001 > Timecounter "i8254" frequency 1193182 Hz > CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x673 Stepping = 3 > > Features=0x387f9ff PAT,PSE36,PN,MMX,FXSR,SSE> > real memory = 201261056 (196544K bytes) > avail memory = 192282624 (187776K bytes) > Preloaded elf kernel "kernel" at 0xc035e000. > VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc02fd882 (122) > VESA: ATI MACH64 > Pentium Pro MTRR support enabled > md0: Malloc disk > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at 0.0 irq 11 > isab0: at device 7.0
local changes to CVS tree
Thus spake Kris Kennaway ([EMAIL PROTECTED]): > On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: > > > I have it fixed now in my local CVS tree. Hopefully Kris will commit > > something to fix it soon :-) I'm just curious: How do people fix stuff in their local CVS tree and sync other FreeBSD changes with that? I mean I have much stuff, which gets M file in the next cvs update, but I'd really like to cvs commit them to my local /home/ncvs, but cvsup will overwrite these changes. Thanks Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing Performance?
Hello, > The last is a dual processor alpha board. Alpha motherboards have > generally better memory IO, including 2.6 Gb/Sec to main memory. > Unfortunately it can only take 2 gig of RAM. AFAIK, that's not a problem, because FreeBSD on alpha can't handle more than that... -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[2]: virtual consoles
> On Tue, Sep 04, 2001 at 11:37:39AM +0800, Igor Podlesny wrote: > [snip] >> >> Screen is a nice thing, I agree. Just one drawback is (Ctrl-A)*N >> consoles (i.e., when you use screen at local console, than log in >> into another box and run screen there. Local screen will see catch >> Ctrl-A and you're forced to type it twice or even more times :) > And then, of course, there is always the 'escape' screenrc command, > allowing you to set a different command character for each session :) > Though.. this would probably lead to a nightmare of misdirected key > presses.. But still, it is there. Yeah, I knew that but considered it was "a nightmare" :) -- Igormailto:[EMAIL PROTECTED] 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: > *I* worked at TFS, I even kept ref.tfs.com alive after Julian went AWOL. I'm well aware of your checkered past... 8-). I guess Julian might pipe up now about the use of the acronym "AWOL"... > Now, remind me again why historians are so picky about "primary > sources" and "secondary sources" for historical information... That would be... Dennis Ritchie? 8-) 8-). > Are we done now ? I guess... > (Apart from Adrians story of course :-) If you think you can beat it out of him... I think we'd all like to sit around the camp fire and listen to it, while stroking our long grey beards... -- Terry 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: > > 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. Old idea. I first saw an ftp version of this in '91 or '92. Last time I went looking for source code, I couldn't find it, so I have no idea who to credit. > > 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. Hopefuly, an http file system will have options to let you specify a username and password, so you can mount password-protected "volumes" that way. Or possibly a place to specify an authentication realm file, giving username/password pairs for the various different realms that might be in the mounted tree. > 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. I can't argue that having that capability on a workstation would be nice. I don't think it's something I'd make a lot of use of, and I'm not really interested in adding it. > 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 think it's more a case of topic drift. This thread started with the observation that URLs were ubiquitous, and asked whether or not they should be pervasive as well. Your - and presumably Mike's - proposed solution doesn't deal with that at all. > > 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. I agree about that. On the other hand, there are commands that take arguments with information that can be put into a url. Because URLs are ubiquitous, it would be nice if those commands would extrat that information for you. I.e. - ncftp grew the ability to deal with FTP urls. fetch carries that even further. I can see wanting a mail composition program that would recognize a mailto URL on the argument line, and pull out the address and subject for you. One of the suggestions that fell out of this was that there be a shell command for doing these kinds of things. While I like that idea, I think the shell command should be a wrapper around some library calls, so that this kind of thing can easily be added to commands where appropriate. Especially since we already have half the functionality - if in a crippled form - in libfetch. This is something I'm willing to work on, and have even started on. I submitted PR 30318, which adds the missing half the functionality to libfetch - but doesn't do any healing of the first half - and a small program that tries to act like the "url" command described earlier on the thread. > I apologize for the miscommunication. I don't think one is necessary, or if one is, I need to apologize as well for missing the change in direction. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SO_REUSEPORT on unicast UDP sockets
Mike Silbersack 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. If you fix or workaround the source IP address problem, and patch/tune the kernel for enough outbound sockets, you can go to 250,000 outbound connections very easily. I used a couple of 1GB memory systems in this configuration to get my 1M (actually, closer to 2M) inbound server connections... obviously, a server doesn't have the port limitation, when it comes to accepting connections. The client TIME_WAIT problem is more an issue for port reuse; for a 2MSL timer in the standard 60 second range, this will basically limit you to 65535/60, or ~1000 outbound connections a second per IP address, as a sustained rate, with a total outstanding count of 65535 * IP_address_count. Unless you set SO_REUSEPORT/SO_REUSEADDR. So for the client side, you are pretty much limited by the bug (or your fix), and whatever you set the 2MSL timer down to, as a sustained rate top end. For most real world uses, apart from test equipment, which will usually just use raw sockets directly, and fake the AYN/ACK for the SYN, and then accept the ACK without an RST, you never really get up into this number of client connections on a single box. > Maybe net or openbsd handle these situations better, I'll have > to check later. I doubt it. Until I did testing on 4.3, no one had really run over 32,766 open sockets in a production server, since at that point, the ucred reference count overflowed, which would result in some strange and very hard to identify crashes, when closing those connections. Alfred fixed this in -current, but it wasn't done consciously to address a known problem, it was done "just in case" (Alfred finds problems like that, and fixes them without necessarily being aware of it... 8-)). It hadn't been MFC'ed back to 4.3 until I identified an actual problem, and the root cause. NetBSD and OpenBSD have some hacks on the server side of the scaling problem (e.g. they have each implemented a SYN cache, which is OK as far as it goes, but is really inferior to the SYN cache and rate halving algorithm code (also against FreeBSD) out of the Pittsburgh Supercomputing Center. I've done a preliminary port of the PSC code to 4.x, actually, though I would need to strip out a number of local changes. One interesting thing about the SYN cache code is that it could use the tcptmpl allocation until it saw the ACK (or even the first data, as was suggested by some of the researchers at that startup in India, a while back, though that's very aggressive). Mostly, you aren't going to see the hashing on both source and detination IP's and ports -- what you'd see in an L2/L3 switch, if you were building one -- which would let you reuse the local pair, so long as it was associated with a different remote pair. That's probably the real long term fix, if there is one. -- Terry 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]>, Terry Lambert writes: >Poul-Henning Kamp wrote: >> 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, you're going off again, without regard for facts. Terry, *I* worked at TFS, I even kept ref.tfs.com alive after Julian went AWOL. *You* have talked to people who worked at TFS. Now, remind me again why historians are so picky about "primary sources" and "secondary sources" for historical information... Are we done now ? (Apart from Adrians story of course :-) -- 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: FreeBSD Security Advisory FreeBSD-SA-01:59.rmuser
On Wed, Sep 05, 2001 at 10:23:57AM +0200, Chojin wrote: > When I apply the patch : > [ /usr/src/usr.sbin/adduser]$patch -p < /home/chojin/patch/rmuser.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |Index: rmuser.perl > |=== > |RCS file: /usr2/ncvs/src/usr.sbin/adduser/rmuser.perl,v > |retrieving revision 1.8.2.4 > |retrieving revision 1.8.2.5 > |diff -u -r1.8.2.4 -r1.8.2.5 > |--- rmuser.perl2001/05/25 15:05:00 1.8.2.4 > |+++ rmuser.perl2001/07/28 12:10:15 1.8.2.5 > -- > Patching file rmuser.perl using Plan A... > Hunk #1 failed at 42. > Hunk #2 failed at 311. > Hunk #3 failed at 340. > Hunk #4 failed at 350. > 4 out of 4 hunks failed--saving rejects to rmuser.perl.rej > done I don't think this is the fault of the patch. Kris PGP signature
Re: What is VT_TFS?
> > > Bill Jolitz approved a 0.5 "interim release" of 386BSD > > > > And then Lynn revoked this, and posted a public message to the world > > stating what obnoxious fiends we were. > > Actually, Lynne didn't have the right to do this; the trademark > was Bill's, so the revocation wasn't valid until Bill did it. > > > > > Some of the people who later split off NetBSD and released the > > > NetBSD 0.8 release had reverse engineered the patchkit format, > > > and built tools to do the same thing. > > > > Actually, no. It was the person who was going to take it from me (I > > could name him, but it wouldn't do much good). The new maintainer > > didn't do anything or respond to email for over 3 months, so Jordan took > > it over from where I left off. > > I was aware that CGD had reverse engineered it. He didn't. Chris never used the patchkit, nor did he ever release any patches. He used some of the patches, but never got involved in anything but his own BSD release. > I wasn't aware > that you had given the tools to the people who later released > the "1000" level patches. He was supposed to be the next maintainer. :( > > NetBSD happened when Lynn's famous email was sent out claiming we were > > all evil incarnate, and that no-one understood them anymore. > > I talked to Lynne and Bill through much of that time; it was > (unfortunately) a discussion well before the fireworks that > resulted in him knowing about common law trademarks. I was > still on good terms with them, well after the NetBSD 0.8 > release, and we mostly "just lost touch", rather than letting > the bickering come between us. I'm suprised you were able to talk to them. Lynn refused to talk to me (or anyone else) on the phone towards the end, and then the famous email was released. > As for the binaries, we had a number of patched floppy images > floating around (I personally couldn't boot the thing at all > until I binary edited the floppy to look for 639 instead of > 640 in the CMOS base memory data registers). Right, but they weren't good enough for a complete install. > Unfortunately, I cut myself out of the loop early on that, > due to the impending purchase of USL by Novell, which went through > in June of 1994, after off shore locations which were not Berne > Convention signatories had been found to house the code in case the > worst happened, so this email is not part of my personal archives. > I hope someone, somewhere has saved it for posterity... It's on 120MB QIC tapes in the drawer next to me. The 'original' 386BSD/FreeBSD development box (prior to WC's involvement) with the tape drive is still in service as my firewall. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What is VT_TFS?
Nate Williams wrote: > You're not the only pack-rat around here. Be careful of your claims, > since they could come back to bite you. I'm willing to be bitten in public, if I'm wrong... always have been. ;-). > ps. I still have my phone-logs of my conversations with Bill as well. ;) Now I'm jealous... I have some yellow legal pads with notes on them, and two of the archives of the "grand unified console driver" online discussions (what a boondoggle that turned out\ to be!), but no real phone logs. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What is VT_TFS?
Nate Williams wrote: > > Bill Jolitz approved a 0.5 "interim release" of 386BSD > > And then Lynn revoked this, and posted a public message to the world > stating what obnoxious fiends we were. Actually, Lynne didn't have the right to do this; the trademark was Bill's, so the revocation wasn't valid until Bill did it. > > Some of the people who later split off NetBSD and released the > > NetBSD 0.8 release had reverse engineered the patchkit format, > > and built tools to do the same thing. > > Actually, no. It was the person who was going to take it from me (I > could name him, but it wouldn't do much good). The new maintainer > didn't do anything or respond to email for over 3 months, so Jordan took > it over from where I left off. I was aware that CGD had reverse engineered it. I wasn't aware that you had given the tools to the people who later released the "1000" level patches. > NetBSD was Chris Demetriou's child after he got fed up with Bill's > promises never coming true. I was the third committer on what would > later become the NetBSD development box, but I still naively assumed > that Bill's promises would eventually come to fruition. All of us pretty much assumed that, at the time. 8-(. > NetBSD happened when Lynn's famous email was sent out claiming we were > all evil incarnate, and that no-one understood them anymore. I talked to Lynne and Bill through much of that time; it was (unfortunately) a discussion well before the fireworks that resulted in him knowing about common law trademarks. I was still on good terms with them, well after the NetBSD 0.8 release, and we mostly "just lost touch", rather than letting the bickering come between us. One thing that was not commonly known at the time, though I guess most people know it now, is that they had had a financial setback, followed by a death in the family, and really weren't in any condition to be doing anything but picking up the pieces; the whole incident was really unfortunate. > Actually, all of the patchkit maintainers (myself, Jordan, and Rod) had > access to your shell software. However, it turned out that avoiding > conflicts was hard, because serialization often required patches upon > patches upon patches upon patches, and at some point, the > creation/maintenance of the patchkit was greater than building a new > release. (Plus the fact that you couldn't install the patches w/out a > running system, and the running system couldn't be installed on certain > hardware w/out patches, causing a catch-22). Yes. It was effectively a single author thing. I always used it by manually applying the patches and resolving any conflicts by hand, and then running a diff between the base tree and the target tree. I never really claimed it as anything other than a vehicle for distributing patches (it sure as heck was no CVS!). As for the binaries, we had a number of patched floppy images floating around (I personally couldn't boot the thing at all until I binary edited the floppy to look for 639 instead of 640 in the CMOS base memory data registers). > Close, but the original posting was by Bill, and the revokation was done > by Lynn. I remember it the other way, but would have to go to tape on it to know for sure... 8-). Originally, Lynne recommended the patchkit and FAQ -- here's an excerpt of a usenet posting of hers from 28 January 1993: | You can get a copy of 386BSD from agate.berkeley.edu (and it's mirror | sites) via anonymous ftp. It is also available on CDROM from Austin | Code Works ([EMAIL PROTECTED]) [Note -- this is unpatched 0.1 -- you should | get the patchkit in /unofficial on agate, and also the FAQ]. > I was involved with the entire affair, and Warren's archive doesn't > include much of what later became 'core' email. Unfortunately, I cut myself out of the loop early on that, due to the impending purchase of USL by Novell, which went through in June of 1994, after off shore locations which were not Berne Convention signatories had been found to house the code in case the worst happened, so this email is not part of my personal archives. I hope someone, somewhere has saved it for posterity... > Also, it doesn't include the phone conversations with Bill and > Lynn, which (obviously) aren't in the public domain. Nor mine. Actually, in California, Utah, and Montanna, and now many more states, so long as one party to the conversation is the one doing the recording, you don't even have to have the periodic "beep" to indicate a recording... even back then. But I never even considered recording my calls, and I rather doubt that anyone else had the foresight to do it, either. It's annoying in retrospect, because I had the equipment for doing passive monitoring without violating the phone company rules on connecting equipment to their wires. 20/20 hindsight... 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IICBUS_READ
In message <[EMAIL PROTECTED]>, s $B$5$s$$$o$/(B:
>
>
>I've look at /sys/dev/iicbus/iiconf.c:
>
>> int
>> iicbus_read(device_t bus, char *buf, int len, int *read, int last, int delay
>)
>> {
>> struct iicbus_softc *sc = (struct iicbus_softc *)device_get_softc(bus);
>>
>> /* a slave must have been started with the appropriate address */
>> if (!sc->started || !(sc->started & LSB))
>> return (EINVAL);
>>
>> return (IICBUS_READ(device_get_parent(bus), buf, len, read, last, de
>lay));
>> }
>
>Where is defined IICBUS_READ ?
/sys/${MACHINE}/compile/${YOURCONF}/iicbus_if.h
This is generated from /sys/dev/iicbus/iicbus_if.m .
Takanori Watanabe
http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html";>
Public Key
Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
IICBUS_READ
I've look at /sys/dev/iicbus/iiconf.c:
> int
> iicbus_read(device_t bus, char *buf, int len, int *read, int last, int delay)
> {
> struct iicbus_softc *sc = (struct iicbus_softc *)device_get_softc(bus);
>
> /* a slave must have been started with the appropriate address */
> if (!sc->started || !(sc->started & LSB))
> return (EINVAL);
>
> return (IICBUS_READ(device_get_parent(bus), buf, len, read, last, delay));
> }
Where is defined IICBUS_READ ?
Seva.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Security Advisory FreeBSD-SA-01:59.rmuser
When I apply the patch : [ /usr/src/usr.sbin/adduser]$patch -p < /home/chojin/patch/rmuser.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: rmuser.perl |=== |RCS file: /usr2/ncvs/src/usr.sbin/adduser/rmuser.perl,v |retrieving revision 1.8.2.4 |retrieving revision 1.8.2.5 |diff -u -r1.8.2.4 -r1.8.2.5 |--- rmuser.perl2001/05/25 15:05:00 1.8.2.4 |+++ rmuser.perl2001/07/28 12:10:15 1.8.2.5 -- Patching file rmuser.perl using Plan A... Hunk #1 failed at 42. Hunk #2 failed at 311. Hunk #3 failed at 340. Hunk #4 failed at 350. 4 out of 4 hunks failed--saving rejects to rmuser.perl.rej done - Original Message - From: "FreeBSD Security Advisories" <[EMAIL PROTECTED]> To: "FreeBSD Security Advisories" <[EMAIL PROTECTED]> Sent: Tuesday, September 04, 2001 9:49 PM Subject: FreeBSD Security Advisory FreeBSD-SA-01:59.rmuser > -BEGIN PGP SIGNED MESSAGE- > > = > FreeBSD-SA-01:59 Security Advisory > FreeBSD, Inc. > > Topic: rmuser contains a race condition exposing /etc/master.passwd > > Category: core > Module: rmuser > Announced: 2001-09-04 > Credits: [EMAIL PROTECTED] > Affects:FreeBSD 4.2-RELEASE, 4.3-RELEASE > FreeBSD 4.3-STABLE prior to the correction date. > Corrected: 2001-07-28 12:10:15 UTC (4.3-STABLE) > 2001-09-04 07:46:57 UTC (RELENG_4_3) > FreeBSD only: Yes > > I. Background > > rmuser is a perl script used to completely remove users from a system. > > II. Problem Description > > When removing a user from the system with the rmuser utility, the > /etc/master.passwd file and it's corresponding database /etc/spwd.db > must be updated. The rmuser script was incorrectly doing this by > creating a new master.passwd file with an unsafe umask and then using > chmod to set its permissions to 0600. Between the time that the file > was created and the time that its permissions were changed the file is > world-readable. > > This is only a minor security vulnerability since the rmuser command > is only used infrequently on most systems, and the attack is highly > timing-dependent. > > All versions of FreeBSD prior to the correction date including FreeBSD > 4.3 contain this problem. The base system that will ship with FreeBSD > 4.4 does not contain this problem since it was corrected prior to the > release. > > III. Impact > > For a brief amount of time while running rmuser, a world-readable copy > of /etc/master.passwd is available. A local attacker who reads this > file can extract password hashes from the copy of /etc/master.passwd. > This information could be used by attackers to escalate their > privileges, possibly yielding root privileges on the local system, by > mounting an offline dictionary attack in order to guess the plaintext > passwords of the accounts on the local system. > > IV. Workaround > > Use the pw(8) utility to remove users instead of rmuser. > > - "pw userdel " will only remove the user from > /etc/passwd, /etc/master.passwd and /etc/group > - "pw -r userdel " will also remove the user's home > dirrectory > > V. Solution > > 1) Upgrade your vulnerable system to 4.3-STABLE or the RELENG_4_3 > security branch, dated after the respective correction dates. > > 2) To patch your present system: download the relevant patch from the > below location, and execute the following commands as root: > > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:59/rmuser.patch > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:59/rmuser.patch.asc > > Verify the detached PGP signature using your PGP utility. > > This patch has been verified to apply to FreeBSD 4.2-RELEASE and > 4.3-RELEASE. It may or may not apply to older, unsupported releases > of FreeBSD. > > # cd /usr/src/usr.sbin/adduser > # patch -p < /path/to/patch > # make depend && make all install > > 3) FreeBSD 4.3-RELEASE systems: > > An experimental upgrade package is available for users who wish to > provide testing and feedback on the binary upgrade process. This > package may be installed on FreeBSD 4.3-RELEASE systems only, and is > intended for use on systems for which source patching is not practical > or convenient. > > If you use the upgrade package, feedback (positive or negative) to > [EMAIL PROTECTED] is requested so we can improve the > process for future advisories. > > During the installation procedure, backup copies are made of the files > which are replaced by the package. These backup copies will be > reinstalled if the package is removed, reverting the system to a > pre-patched state. > > # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packa
Re: ipnat, ipf, ipfstat devices not configured
Hello, #dmesg | grep IP plip0: on ppbus0 IP Filter: v3.4.16 initialized. Default = pass all, Logging = enabled IP Filter: already initialized IP Filter: v3.4.16 unloaded module_register_init: MOD_LOAD (IP Filter: v3.4.16, c0388278, 0) error 16 It seems there is an error in the module. I'll test with generic when I'll have time :o) - Original Message - From: "Fernando Gleiser" <[EMAIL PROTECTED]> To: "Chojin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, September 04, 2001 9:51 PM Subject: Re: ipnat, ipf, ipfstat devices not configured > On Tue, 4 Sep 2001, Chojin wrote: > > > 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 > > It seems you don't have IP Filter support in your kernel. The kernel options > are fine, maybe you recompiled the kernel but forgot to install it. > > Do a 'dmesg | grep IP', a line like this should apear: > > IP Filter: v3.4.16 initialized. Default = pass all, Logging = enabled > > Try booting GENERIC and kldload ipl, to load IP Filter as a module. > I load ipf as a module, to keep it up to date with Darren's fixes. The upgrade > is easier. > > > Hope This helps. > > > Fer > > > > > > #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-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: What is VT_TFS?
> > 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, you're going off again, without regard for facts. > > Remember the last time FreeBSD history came up, I proved Nate > mistaken in his claim that my authorship of the original 386BSD > FAQ was "revisionist history". No you didn't. You changed the questions. :) > You can check these facts out in the archives on Minnie; I can > also provide almost every email I ever sent or received (if it > resulted in a response from me to the author), from 1988 forward, > since I have it all archived, since even at the time, I felt it > might end up being an important historical record. At the very > least, it has provided me with a rich source of information from > which to draw, in order to study "Open Source" projects in general, > and 386BSD, FreeBSD, and NetBSD, in particular. You're not the only pack-rat around here. Be careful of your claims, since they could come back to bite you. Nate ps. I still have my phone-logs of my conversations with Bill as well. ;) 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 ?
It seems Steve Roome wrote: > 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). Yes, and support has been committed to both -current & -stable. > I've got one of these : > > ad0: 39266MB [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). Well, thanks :) Anyhow, the problem at hand is more like bad chipsets, there is ALOT of ATA chipsets thats not working right when used the way needed for tagged queuing. That said, the IBM DTLA's series of drives are extremely picky about power (that makes them unusable in at least California right :)) which I've seen cause trouble on highly loaded machines. However I run 4 of them here locally with tags, and they get about as much beating as they can handle, not a single error yet, so it definitly works, you just need the right environment for them. So what chipset does you machine have ? that could very well be the problem here. -Søren 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: > 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, you're going off again, without regard for facts. Remember the last time FreeBSD history came up, I proved Nate mistaken in his claim that my authorship of the original 386BSD FAQ was "revisionist history". You can check these facts out in the archives on Minnie; I can also provide almost every email I ever sent or received (if it resulted in a response from me to the author), from 1988 forward, since I have it all archived, since even at the time, I felt it might end up being an important historical record. At the very least, it has provided me with a rich source of information from which to draw, in order to study "Open Source" projects in general, and 386BSD, FreeBSD, and NetBSD, in particular. I am only willing to open up the non-private email sent or received, and then only with considerable incentive (it is a very large archive). Alternately, you can go to Warren's archive and look there, before making accusations of revisionism. However, if you insist, I can and will happily quote large sections of it to this mailing list, in support of any contended claims of inaccuracy... Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What is VT_TFS?
> > > 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). > > FWIW: This is all archived on Minnie, thanks to Warren Toomey. Sure, and I've got archives of it as well. > I believe that Julian was the first corporately employed > person, who had at least part of his paid job as working on > the 386BSD/FreeBSD code. Yes, and the original SCSI system was Julian's, which was later replaced by CAM. > Bill Jolitz approved a 0.5 "interim release" of 386BSD And then Lynn revoked this, and posted a public message to the world stating what obnoxious fiends we were. As the person who spoke with both Bill and Lynn getting their approval (Jordan did as well), I'm *very* familiar with the process. > Some of the people who later split off NetBSD and released the > NetBSD 0.8 release had reverse engineered the patchkit format, > and built tools to do the same thing. Actually, no. It was the person who was going to take it from me (I could name him, but it wouldn't do much good). The new maintainer didn't do anything or respond to email for over 3 months, so Jordan took it over from where I left off. NetBSD was Chris Demetriou's child after he got fed up with Bill's promises never coming true. I was the third committer on what would later become the NetBSD development box, but I still naively assumed that Bill's promises would eventually come to fruition. NetBSD happened when Lynn's famous email was sent out claiming we were all evil incarnate, and that no-one understood them anymore. Soon afterward NetBSD 0.8 was released, but Adam Glass (the owner of the second account on the NetBSD development box) was a big 68K fan, so his influence (as well as Chris's) made NetBSD into a cross-platform OS. > Progress was made on the 386BSD 0.5 release under the auspices > of the patchkit maintainers, who had their position of control > because I did not distribute the patchkit patch making shell > scripts very widely, in order to ensure serialization, so that > the patches, when applied, would work, have proper dependency > tracking, and not result in conflicts. Actually, all of the patchkit maintainers (myself, Jordan, and Rod) had access to your shell software. However, it turned out that avoiding conflicts was hard, because serialization often required patches upon patches upon patches upon patches, and at some point, the creation/maintenance of the patchkit was greater than building a new release. (Plus the fact that you couldn't install the patches w/out a running system, and the running system couldn't be installed on certain hardware w/out patches, causing a catch-22). > There was an angry posting on Usenet by Lynne Jolitz; in it, > she claimed that 1/3 of the patchkit was good, 1/3 was benign > (but unnecessary), and 1/3 was crap. Then she would not say > which 1/3 was which; this pissed off more people than the > original claim that only 1/3 of the code was any good. > > After much sniping back and forth, Bill Jolitz posted, and > revoked his previous permission to use the 386BSD name (a > common law trademark belonging to him), and therefore he had > effectively scuttled the interim release under the 386BSD > name. Close, but the original posting was by Bill, and the revokation was done by Lynn. > Unwilling to throw away many months of work, it was decided to > go forward with the release, under the name FreeBSD 0.1. > > Walnut Creek CDROM suggested that the version number be changed > to "1.0", in order to make it an easier sell on CDROM. > > Check with Warren, if you don't believe this account. I was involved with the entire affair, and Warren's archive doesn't include much of what later became 'core' email. Also, it doesn't include the phone conversations with Bill and Lynn, which (obviously) aren't in the public domain. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What is VT_TFS?
Nate Williams wrote: > > 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). FWIW: This is all archived on Minnie, thanks to Warren Toomey. I believe that Julian was the first corporately employed person, who had at least part of his paid job as working on the 386BSD/FreeBSD code. Bill Jolitz approved a 0.5 "interim release" of 386BSD, as his recent family troubles and recent contract with Sun precluded him getting the promised 1.0 release out any time soon. Some of the people who later split off NetBSD and released the NetBSD 0.8 release had reverse engineered the patchkit format, and built tools to do the same thing. Not understanding the fact that the patchkit was in fact a simple, single user revision control system that I had hacked together, they released patches of their own, starting at #1000. This resulted in problems with serialization, and, I believe, was one of the main factors in their going off on their own. Progress was made on the 386BSD 0.5 release under the auspices of the patchkit maintainers, who had their position of control because I did not distribute the patchkit patch making shell scripts very widely, in order to ensure serialization, so that the patches, when applied, would work, have proper dependency tracking, and not result in conflicts. There was an angry posting on Usenet by Lynne Jolitz; in it, she claimed that 1/3 of the patchkit was good, 1/3 was benign (but unnecessary), and 1/3 was crap. Then she would not say which 1/3 was which; this pissed off more people than the original claim that only 1/3 of the code was any good. After much sniping back and forth, Bill Jolitz posted, and revoked his previous permission to use the 386BSD name (a common law trademark belonging to him), and therefore he had effectively scuttled the interim release under the 386BSD name. Unwilling to throw away many months of work, it was decided to go forward with the release, under the name FreeBSD 0.1. Walnut Creek CDROM suggested that the version number be changed to "1.0", in order to make it an easier sell on CDROM. Check with Warren, if you don't believe this account. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
