On Thu, Aug 08, 2002 at 03:48:14PM +, Bruce M Simpson wrote:
> Has anybody thought about hacking the above to support building packages
> outside of the ports tree, and without installing them? Strikes me as
> something that could be neatly solved with judicious use of chroot(1).
>
> This is
Sent with permission; the original to which this was a response
was supposed to go to -hackers.
(Captured for the next person with the same questions).
ouyang kai wrote:
>
>Part 1.1.1Type: Plain Text (text/plain)
> Encoding: quoted-printable
>
>
Peter Wemm wrote:
> Maxim Sobolev wrote:
> > I also would like to hear from you whether or not you think that we
> > need all those gethostbyXXX_r(3) functions.
>
> Yes. Because autoconf looks for them and will assume non-reentrancy if
> they are not present. Also, for source compatability with
David Xu wrote:
> localtime() etc. are candidate to make them use per thread
> storage.
Any call that returns a pointer to a statically allocated
data area is a candidate, by definition, I think.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the b
>
> No. I don't think any of the _r functions are needed, so long
> as the results are not cached by pointer instead of a copy,
> before passing them from one thread to another. It's a risk on
> the clobber case of a call with a cached reference outstanding
> but not processed by another thread
On Mon, 12 Aug 2002, Peter Wemm wrote:
> Maxim Sobolev wrote:
> > I also would like to hear from you whether or not you think that we
> > need all those gethostbyXXX_r(3) functions.
>
> Yes. Because autoconf looks for them and will assume non-reentrancy if
> they are not present. Also, for sour
* Andrew R. Reiter <[EMAIL PROTECTED]> [020805 09:15] wrote:
> On Mon, 5 Aug 2002, Alfred Perlstein wrote:
>
> :Can anyone point out or provide me with a suite to regression test
> :sysv_ipc, specifically semaphores, message queues and shared memory?
> :
> :I'm working on SMP locking those subsys
My buddies and I were average
people, just like you...Then we had our great idea...find
young hot girls and proposition them to fool
around on video tape.Armed with a camera, a smooth tongue, and a couple
of bucks we have made quite a few interesting videos!BEST OF ALL... MY SITE IS 100% FREE
Sorry, I can't find anything in the archives, and two submissions to
-questions got nothing.
how to remove a route when the destination is totally fubar?
today's syslog has 500 megs of:
Aug 12 12:35:27 mx3 arplookup 255.255.255.0 failed: host is not on local
network
Aug 12 12:35:27 mx3 arpres
On Sun, 11 Aug 2002, Sean Hamilton wrote:
> From: "Doug White" <[EMAIL PROTECTED]>
> > You should check that your network configuration is correct first, then
> > use tcpdump to locate the offender and report them to your provider. They
> > can ask the owner of said machine politely to install th
My buddies and I were average
people, just like you...Then we had our great idea...find
young hot girls and proposition them to fool
around on video tape.Armed with a camera, a smooth tongue, and a couple
of bucks we have made quite a few interesting videos!BEST OF ALL... MY SITE IS 100% FREE
Maxim Sobolev wrote:
> I also would like to hear from you whether or not you think that we
> need all those gethostbyXXX_r(3) functions.
Yes. Because autoconf looks for them and will assume non-reentrancy if
they are not present. Also, for source compatability with linux and
solaris and just ab
Maxim Sobolev wrote:
> > You may also want to consider the use of a .init and .fini
> > section for the code, to permit the creation of an initial
> > lookup context chunk; this is kind of a tradeoff, but it will
> > mean that a server will not have to do the recheck each time.
> > The .fini secti
ouyang kai wrote:
>
>Part 1.1Type: Plain Text (text/plain)
>Encoding: quoted-printable
| When the kernel process this code to check the SI_SUB_DRIVERS,
| it would find the registed 'fxp' device(fxp_probe), right?
Not exactly. Let's expand the macros manually:
On Thu, 8 Aug 2002, Bruce M Simpson wrote:
BMS> Has anybody thought about hacking the above to support building packages
BMS> outside of the ports tree, and without installing them? Strikes me as
BMS> something that could be neatly solved with judicious use of chroot(1).
BMS>
BMS> This is somethi
On Mon, 12 Aug 2002, Maxim Sobolev wrote:
> Daniel Eischen wrote:
> >
> > On Mon, 12 Aug 2002, Maxim Sobolev wrote:
> > > Folks,
> > >
> > > Attched please find two patches based on bin/29581 PR to make FreeBSD
> > > resolver thread-safe. They represent two approaches to reach this goal
> > > - t
Daniel Eischen wrote:
>
> On Mon, 12 Aug 2002, Maxim Sobolev wrote:
> > Folks,
> >
> > Attched please find two patches based on bin/29581 PR to make FreeBSD
> > resolver thread-safe. They represent two approaches to reach this goal
> > - the first is to introduce reentrant versions of the standar
Terry Lambert wrote:
>
> Maxim Sobolev wrote:
> > Attched please find two patches based on bin/29581 PR to make FreeBSD
> > resolver thread-safe. They represent two approaches to reach this goal
> > - the first is to introduce reentrant versions of the standard
> > gethostbyXXX(3) APIs, similar t
On Mon, 12 Aug 2002, Maxim Sobolev wrote:
> Folks,
>
> Attched please find two patches based on bin/29581 PR to make FreeBSD
> resolver thread-safe. They represent two approaches to reach this goal
> - the first is to introduce reentrant versions of the standard
> gethostbyXXX(3) APIs, similar to
Dear Terry, (*((*sipp)->func))((*sipp)->udata); I saw the corresponding code based on your hints. I have some questions. When the kernel process this code to check the SI_SUB_DRIVERS, it would find the registed 'fxp' device(fxp_probe), right? If the 'fxp' device is exist, the kernel will try
Maxim Sobolev wrote:
> Attched please find two patches based on bin/29581 PR to make FreeBSD
> resolver thread-safe. They represent two approaches to reach this goal
> - the first is to introduce reentrant versions of the standard
> gethostbyXXX(3) APIs, similar to ones existing in other unices, a
ouyang kai wrote:
>
>Part 1.1.1Type: Plain Text (text/plain)
> Encoding: quoted-printable
>
> Name: kernel_init_problem.txt
>kernel_init_problem.txtType: Plain Text (text/plain)
> Encoding: quoted-printable
If
I've been playing around with using mtree as a lightweight replacement
for tripwire, and it seems to work quite nicely. There are a few bits and
pieces: (1) a patch to make the -X exclude-file facility slightly more
flexible and easy-to-manage; (2) a script for creating the mtree spec
file contain
Folks,
Attched please find two patches based on bin/29581 PR to make FreeBSD
resolver thread-safe. They represent two approaches to reach this goal
- the first is to introduce reentrant versions of the standard
gethostbyXXX(3) APIs, similar to ones existing in other unices, and
the second one is
Dear Terry, >See /usr/src/sys/kernel.h. It is done using linker sets and>SYSINIT.Hmm¡. Thank you!I find the mi_startup() function in /sys/kern/init_main.c, there are some code as follow:for (sipp = sysinit; sipp < sysinit_end; sipp++) { if ((*sipp)->subsystem == SI_SUB_DUMMY) continue; /* ski
ouyang kai wrote:
>
>Part 1.1Type: Plain Text (text/plain)
>Encoding: quoted-printable
See /usr/src/sys/kernel.h. It is done using linker sets and
SYSINIT.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the messa
Hi Everybody, I am a jackaroo to FreeBSD kernel. I have a question about how the kernel add all devices. For example, in NetBSD, I can find the code in /sys/kern/init_main.c: /* Attach pseudo-devices. */for (pdev = pdevinit; pdev->pdev_attach != NULL; pdev++) (*pdev->pdev_attach)(p
Hi Everybody, I am a jackaroo to FreeBSD kernel. I have a question about how the kernel add all devices. For example, in NetBSD, I can find the code in /sys/kern/init_main.c: /* Attach pseudo-devices. */ for (pdev = pdevinit; pdev->pdev_attach != NULL; pdev++) (*pdev->pdev_atta
28 matches
Mail list logo
