Re: Building ports into packages, outside of /usr/ports
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 something which was raised at the FreeBSD UK Users Group meeting > last night, so it's bugging me. Sure. It's something FreeBSD has been doing for almost four years now. See ports/Tools/portbuild. :-] It's designed for mass package building though, not just one. Its primary purposes are for testing, occasional package regeneration, and release package generation. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How the kernel add the devices when the kernel start
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
>
>Name: kernel_init_problem3.txt
>kernel_init_problem3.txtType: Plain Text (text/plain)
>Encoding: quoted-printable
| If I have two 'fxp' devices in my box, then, the system should have
| the same vars, Why don't they conflict ? How do they register?
PCI devices are enumerated by the PCI bus enumerator. The
enumerator goes through the IDs of all the cards that exist,
and calls the driver probe routine if it matches the Vendor
and product ID reported on the PCI bus. The enumerator lives
in /usr/src/sys/pci/pci.c.
Each matching instance has a device instance structure allocated,
which is unique to the device. PCI also guarantees that two
identical devices get slot-based memory ranges and other resources
assigned, so they are not conflicting (cards are all in different
slots, by definition).
Thus the per device instance structure keeps them seperate, and
the bus ensures there are no conflicts.
For PCI cards that map memory to well known locations, there can
be conflicts (this is especially true of vide cards). Most do
not map at a fixed location, but instead map wherever the POST
initialization of the BIOS tells them is available.
So:
1) Machine powers on
2) Machine POSTs (Power On Self Tests)
3) BIOS POST code assigns card specific resources
4) Kernel enumerates PCI devices
5) Driver matches vendor/device ID
6) Per device instance structure is allocated
7) Per device instance structure is filled out from
values set up by BIOS POST
8) Card is attached and interrupt handler is registered
with address of per device instance structure
9) Interrupts come in
10) Interrupt sharing code uses PCI command to ask which
card(s) cause the interrupt
11) Device driver entry point is called for card that
cause the interrupt with address of per device
context structure
12) Per device context structure address is converted from
void pointer to device specific structure pointer
static void
fxp_intr(void *xsc)
{
struct fxp_softc *sc = xsc;
13) And interrupt processing proceeds to completion
| PS: I can get the device name from the link-level sockaddr(struct
| sockaddr_dl's member sdl_data:"fxp0" and "fxp1"), right?
Yes, but there's really no reason to want it. It's only for
displaying to the user.
| >This *eventually* calls the probe, and, if it finds a device,
| >the attach, so yes, many function calls deep.
| I think I did not ask the question clearly.
| Now, I know in the mi_startup(), the kernel complete the function of
|'module_register_init'.
| But, When and How the kernel 'eventually' calls the probe and attach?
The bus enumerator enumerates the PCI devices. The SYSINIT() code
(via DRIVER_MODULE) only registers the device hierarchy data
structure.
The actual top level driver in the hierarchy does the work; on
i386, this is the "nexus" driver. See: /usr/src/sys/i386/i386/nexus.c.
This is done in configure():
/* nexus0 is the top of the i386 device tree */
device_add_child(root_bus, "nexus", 0);
/* initialize new bus architecture */
root_bus_configure();
located in: /usr/src/sys/i386/i386/autoconf.c. The declaration
for this call is:
SYSINIT(configure2, SI_SUB_CONFIGURE, SI_ORDER_THIRD, configure, NULL);
If you look in /usr/src/sys/sys/kernel.h, you see:
[...]
SI_SUB_CREATE_INIT = 0x250,/* create the init process */
SI_SUB_DRIVERS = 0x310,/* Let Drivers initialize */
SI_SUB_CONFIGURE= 0x380,/* Configure devices */
SI_SUB_VFS = 0x400,/* virtual file system*/
[...]
...in other words, all the drivers get registered into the device
hierarchy under the root ("nexus") in the SI_SUB_DRIVERS phase,
and then they are initialized in the SI_SUB_CONFIGURE phase.
Note that when you load a device driver as a module, the device
hierarchy is already present. Therefore the device registers
into an existing hierarchy. The probe is called (in the PCI case)
only on "unclaimed" devices. For ISA and other devices, there is
bus-specific behaviour. In the ISA case, it can actively probe
(most ISA devices require active probing), so it can destabilize
your system (by poking things that aren't ISA cards, and which do
not like it when they are poked); non-legacy drivers "just work".
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
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 linux and > solaris and just about everything else that implements this stuff. The > expectation is that gethostbyXXX is non-safe and that gethostbyXXX_r is > safe. If you can make the non_r versions safe then that is a bonus I guess. Autoconf is evil pure and simple, from the 8th dimension. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
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 body of the message
Re: Thread-safe resolver [patches for review]
>
> 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 which is not an issue with
> the _r functions, which require that you pass the storage down.
>
> Of course, if you pass down per thread storage, you could have
> the same problem if you didn't copy rather than reference the
> results before passing to another thread by address.
>
> Given that, per thread allocations ("thread local storage")
> makes more sense than allocate/free fights between threads
> based on who's responsible for owning the memory after an
> inter-thread call. 8-).
>
> -- Terry
localtime() etc. are candidate to make them use per thread
storage.
David Xu
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
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 source compatability with linux and > solaris and just about everything else that implements this stuff. The > expectation is that gethostbyXXX is non-safe and that gethostbyXXX_r is > safe. If you can make the non_r versions safe then that is a bonus I guess. You are aware that Solaris's version of gethostbyname_r() has a different interface than Linux's (glibc 2.whatever) variant, and that both differ from AIX's gethostbyname_r()... right? Also, some systems (HP-UX 11 and Irix [not sure, though]) have a reentrant gethostbyname(), possibly alongside a _r version marked "obsolete". So, even though I agree that having _r versions might be useful, neither autoconf (which has to be smarter than just looking for a "_r" version), nor source compatibility should be considered the main reasons, IMHO. $.02, /Mikko Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysv_ipc regression suite
* 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 subsystems and it would be a major > :time saver if someone could point me to something that already > :exists (or code one up for me). > : > > Not sure if you did this or not, sorry if so, but can you add your doing > the sysv ipc locking work on the SMP todo page? :D Where and how can i do this? -- -Alfred Perlstein [[EMAIL PROTECTED]] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Hey, whats up?
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!! If this sounds like something of interest to you, http:[EMAIL PROTECTED]";>click here You will be glad you did. If you never want to hear from me again, please click here and I will remove you from all future mailings. - Get your free WebMail account from Sympatico-Lycos at www.sympatico.ca - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Routing table: removing an invalid entry
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 arpresolve: can't allocate llinfo for 255.255.255.0rt thanks Len >man route? of course, I have been there, I have been to the handbook, I've been to google/bsd, and my own -question -net -isp archives, and can't find the answer. What does you "man route" say about trashing trashy entries? # route delete "64\&0x7f01" route: bad address: 64\&0x7f01 # route delete '64\&0x7f01' route: bad address: 64\&0x7f01 # route delete `64\&0x7f01` 64&0x7f01: Command not found. route: writing to routing socket: Invalid argument delete net : Invalid argument Len To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: arplookup: host is not on local network
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 the patches or set
> > /proc flags to disable that behavior. You can, of course, comment out the
>
> Which /proc flags? Indeed it is a linux box, the firewall, which I have
> access to. My coworker, the administrator of this box, has simply turned a
> blind eye to this, on the grounds that it's not actually causing problems,
> just noise... but if it's a simple tweak, I'm sure he could be bribed with
> caffeine or somesuch.
I don't recall, its under /proc/sys/net most likely ... you can google for
it.
> > printfs, or hide it behind log_arp_wrong_iface which is controlled by the
> > sysctl net.link.ether.inet.log_arp_wrong_iface. The file you want to
> > modify in that case is src/sys/netinet/if_ether.c.
>
> Thanks, looks like that sysctl is what I've been looking for. Though you
> seem to indicate I would have to modify the kernel to achieve this, it seems
> to be that way already -- perhaps a recent thing? Regardless, I find it
> somewhat surprising my googling didn't point me in this direction.
log_arp_wrong_iface was in 4.5 I think, but you do need to do a minor hack
to put an if(){} block around the offending printf.
--
Doug White| FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Hey, whats up?
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!! If this sounds like something of interest to you, http:[EMAIL PROTECTED]";>click here You will be glad you did. If you never want to hear from me again, please click here and I will remove you from all future mailings. - Get your free WebMail account from Sympatico-Lycos at www.sympatico.ca - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
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 about everything else that implements this stuff. The expectation is that gethostbyXXX is non-safe and that gethostbyXXX_r is safe. If you can make the non_r versions safe then that is a bonus I guess. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
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 section would aloow auto-cleanup. This may be a
> > necessity for a long running program that uses a shared object
> > to perform the thread creation and lookup (you could leak
> > memory, otherwise).
>
> Could you please elaborate how exactly memory could be leaked in this
> case, if the program does correctly shut down all its threads?
Create PIC object foo.so.
Link PIC object foo.so against libc.so.
Call dlopen to load module foo.so into program "bob".
Call function in foo.so from program "bob".
Function in foo.so creates two threads, one for IPv4 lookup,
another for IPv6 lookup to cause lookups to proceed
concurrently.
Lookup completes.
Unload module foo.so.
-> leak memory in libc.so image
The assumption (which is potentially wrong) is that the program
will correctly shut down all its threads, when in fact it was a
module not under the programs control that created and used the
threads.
The leak depends on:
1) A pool of worker threads being created and left around
or the purpose of simultaneous resolution
2) The parent shutting down the module without explicitly
dealing with the threads (basically, code which would
need to live in ".fini" of the foo.so, and could not be
automatically triggered on unload of foo.so any other way).
I think that parallel IPv6/IPv4 resolution presented as a single
serial interface is a high probability implementation with the
support for threaded access to the resolver, particularly with
the Mozilla code acting the way it does.
> I also would like to hear from you whether or not you think that we
> need all those gethostbyXXX_r(3) functions.
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 which is not an issue with
the _r functions, which require that you pass the storage down.
Of course, if you pass down per thread storage, you could have
the same problem if you didn't copy rather than reference the
results before passing to another thread by address.
Given that, per thread allocations ("thread local storage")
makes more sense than allocate/free fights between threads
based on who's responsible for owning the memory after an
inter-thread call. 8-).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: How the kernel add the devices when the kernel start
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:
--
DRIVER_MODULE(if_fxp, pci, fxp_driver, fxp_devclass, 0, 0);
->
static driver_t *if_fxp_pci_driver_list[] = { &fxp_driver };
static struct driver_module_data if_fxp_pci_driver_mod = {
0, 0,
"pci",
if_fxp_pci_driver_list,
(sizeof if_fxp_pci_driver_list) / (sizeof if_fxp_pci_driver_list[0]),
&fxp_devclass
};
static moduledata_t if_fxp_pci_mod = {
"pci/if_fxp",
driver_module_handler,
&if_fxp_pci_driver_mod
};
DECLARE_MODULE(if_fxp_pci, if_fxp_pci_mod, SI_SUB_DRIVERS, SI_ORDER_MIDDLE)
->
SYSINIT(if_fxp_pcimodule, SI_SUB_DRIVERS, SI_ORDER_MIDDLE,
module_register_init, &if_fxp_pci_mod)
->
struct sysinit if_fxp_pcimodule_sys_init {
SI_SUB_DRIVERS,
SI_ORDER_MIDDLE,
module_register_init,
&if_fxp_pci_mod
};
-> in init_main.c:
module_register_init( &if_fxp_pci_mod);
/--
So the answer is that it calls the function "module_register_init"
with the address of the moduledata_t structure whose contents are:
--
static moduledata_t if_fxp_pci_mod = {
"pci/if_fxp",
driver_module_handler,
&{
0, 0,
"pci",
if_fxp_pci_driver_list,
1,
&fxp_devclass
}
};
/--
| If the 'fxp' device is exist, the kernel will try to attach
| it(fxp_attach), right?
This *eventually* calls the probe, and, if it finds a device,
the attach, so yes, many function calls deep.
| Another, If we do not compile the 'vr' device into the kernel
| and we do not load the corresponding 'ko', so the kernel will
| not check the device, that is to say, the 'vr' device does not
| registe to kernel, right?
Yes. Unless the .ko (kernel module) version gets loaded, a
driver must be statically linked into the kernel, or it will
not be called to try and probe for devices that it matches.
| 1. When the kernel process the specified device, the 'func'
| means what? For example: the member 'if_ioctl' of the
| structure 'ifnet', when the kernel process the 'fxp' device,
| I know it should call the function 'fxp_ioctl'. But I do not
| the 'func' means what when it check SI_SUB_DRIVERS.
In this case, the macros make it mean the function named
module_register_init().
| 2. In NetBSD, I can find main() function in init_main.c, but
| in FreeBSD, I could not find it, I am puzzled about the place
| of the FreeBSD main process.
This is not well documented, and it has changed recently, as
people have gained an understanding for the boot process, and
screwed around with the code there, so any documentation is
out of date pretty quickly. That's the problem with documenting
things: there is so little documentation that as soon as something
is documented, people understand it and jump on it and change it
because they now understand it. Unfortunately people can't seem
to leave working code alone, expecially if it's the only code they
understand (understanding broken code would be too much like work,
I guess...).
The short answer is:
mi_startup().
The longer answer is:
bootstrap code (boot0, boot1+boot2)
-- this is the entry point from the BIOS
btext() (in locore.s; called locorestart() on Alpha)
-- this is the entry point from the bootstrap
identify_cpu()
create_pagetables()
begin() (in relocated address space)
mi_startup()
-- this is the entrypoint to the machine
independent startup code that will be the
same no matter what type of machine you
run FreeBSD on.
Which one is really "main()" depends on your philosophy, and
who has been rearranging the deck chairs in locore.s this week.
8-(.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Building ports into packages, outside of /usr/ports
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 something which was raised at the FreeBSD UK Users Group meeting BMS> last night, so it's bugging me. Hmm, did you look at /usr/ports/Tools/portbuild and /usr/ports/Tools/scripts/release ? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
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 > > > - 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 to make gethostbyXXX(3) returning data placed into > > > per-thread storage when linked with libc_r. I like the latter approach > > > more, since it doesn't introduce new non-standard APIs. > > > > > > I would like to hear any comments and suggestions on the proposed > > > patches, as well as to opinions about which path to chose. > > > > Why do you need uthread_resolv.c? You should be able to thread > > calls by checking __isthreaded. Just keep everything in libc. > > If there are missing stubs for some pthread_* routines (I think > > everything you need is in -current's libc), then add them. > > Why do we have uthread_error.c then? Also it will add penalty to every > access to _res_data structure even in non-threaded case. Take a look at everything else in libc. What about malloc? It does the same thing and checks __isthreaded. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
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 standard > > gethostbyXXX(3) APIs, similar to ones existing in other unices, and > > the second one is to make gethostbyXXX(3) returning data placed into > > per-thread storage when linked with libc_r. I like the latter approach > > more, since it doesn't introduce new non-standard APIs. > > > > I would like to hear any comments and suggestions on the proposed > > patches, as well as to opinions about which path to chose. > > Why do you need uthread_resolv.c? You should be able to thread > calls by checking __isthreaded. Just keep everything in libc. > If there are missing stubs for some pthread_* routines (I think > everything you need is in -current's libc), then add them. Why do we have uthread_error.c then? Also it will add penalty to every access to _res_data structure even in non-threaded case. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
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 to ones existing in other unices, and > > the second one is to make gethostbyXXX(3) returning data placed into > > per-thread storage when linked with libc_r. I like the latter approach > > more, since it doesn't introduce new non-standard APIs. > > > > I would like to hear any comments and suggestions on the proposed > > patches, as well as to opinions about which path to chose. > > 1) Allocate the per thread storage as a single blob, and > set the pointers into it, instead of using seperate > allocations. This will have the side effect of letting > you free it, all at once, and will tend to make it > faster on each first use per thread, anyway. You can > do this by making a meta structure containing the list > of structures to be allocated, and then setting the > pointers to the addresses of the structure subelements. Ok, I'll do it. > 2) Note somewhere in the man page that this makes it so > you can not pass the results off to another thread by > reference, unless you copy them once there (i.e. you > are not allowed persistant references accross threads). > It seems to me the most likely use would be to permit > a seperate thread (or threads) to be used to resolve > concurrently, and/or with other operations. The upshot > of this is that holding a reference would mean that you > could not initiate another lookup on the lookup worker > thread(s) until the reference was freed. Yuip, I'll do it as well. > 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 section would aloow auto-cleanup. This may be a > necessity for a long running program that uses a shared object > to perform the thread creation and lookup (you could leak > memory, otherwise). Could you please elaborate how exactly memory could be leaked in this case, if the program does correctly shut down all its threads? I also would like to hear from you whether or not you think that we need all those gethostbyXXX_r(3) functions. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Thread-safe resolver [patches for review]
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 ones existing in other unices, and > the second one is to make gethostbyXXX(3) returning data placed into > per-thread storage when linked with libc_r. I like the latter approach > more, since it doesn't introduce new non-standard APIs. > > I would like to hear any comments and suggestions on the proposed > patches, as well as to opinions about which path to chose. Why do you need uthread_resolv.c? You should be able to thread calls by checking __isthreaded. Just keep everything in libc. If there are missing stubs for some pthread_* routines (I think everything you need is in -current's libc), then add them. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How the kernel add the devices when the kernel start
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 to attach it(fxp_attach), right? Another, If we do not compile the 'vr' device into the kernel and we do load the corresponding 'ko',so the kernel will not check the device, that is to say, the 'vr' device does not registe to kernel, right? But, I have some problem :1. When the kernel process the specified device, the 'func' means what? For example: the member 'if_ioctl' of the structure 'ifnet', when the kernel process the 'fxp' device, Iknow it should call the function 'fxp_ioctl'. But I do not the 'func' means what when it check SI_SUB_DRIVERS.2. In NetBSD, I can find main() function in init_main.c, but in FreeBSD, I could not find it, I am puzzled aboutthe place of the FreeBSD main process. Thank you so much!Best Regards Ouyang Kai Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Re: Thread-safe resolver [patches for review]
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, and > the second one is to make gethostbyXXX(3) returning data placed into > per-thread storage when linked with libc_r. I like the latter approach > more, since it doesn't introduce new non-standard APIs. > > I would like to hear any comments and suggestions on the proposed > patches, as well as to opinions about which path to chose. 1) Allocate the per thread storage as a single blob, and set the pointers into it, instead of using seperate allocations. This will have the side effect of letting you free it, all at once, and will tend to make it faster on each first use per thread, anyway. You can do this by making a meta structure containing the list of structures to be allocated, and then setting the pointers to the addresses of the structure subelements. 2) Note somewhere in the man page that this makes it so you can not pass the results off to another thread by reference, unless you copy them once there (i.e. you are not allowed persistant references accross threads). It seems to me the most likely use would be to permit a seperate thread (or threads) to be used to resolve concurrently, and/or with other operations. The upshot of this is that holding a reference would mean that you could not initiate another lookup on the lookup worker thread(s) until the reference was freed. 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 section would aloow auto-cleanup. This may be a necessity for a long running program that uses a shared object to perform the thread creation and lookup (you could leak memory, otherwise). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hi, how the kernel add the devices
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 you are talking about the fxp driver, then you need to look in /usr/src/sys/dev/fxp/if_fxp.c, around line 240: DRIVER_MODULE(if_fxp, pci, fxp_driver, fxp_devclass, 0, 0); DRIVER_MODULE(if_fxp, cardbus, fxp_driver, fxp_devclass, 0, 0); DRIVER_MODULE(miibus, fxp, miibus_driver, miibus_devclass, 0, 0); The definition of DRIVER_MODULE is variant, based on whether the code is a loadable module, or is compiled into the kernel. The original intent of the SYSINIT code was to erase the distinction between code statically linked into the kernel, and code loaded later, as a loadable module. Specifically, the DRIVER_MODULE() macro uses the DECLARE_MODULE(); see /usr/src/sys/sys/bus.h, in which it specifies SI_SUB_DRIVERS as the init_main.c code sort order, and the sub-order within that as SI_ORDER_MIDDLE. The DECLARE_MODULE() macro encapsulates a SYSINIT() entry; see /usr/src/sys/sys/module.h. The result is that the init_main.c code calls the entry point on startup to probe the device (see /usr/src/sys/dev/fxp/if_fxp.c). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
using mtree as tripwire
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 containing all of the checksums; and (3) an /etc/periodic/security script to do the mtree checksum comparison with reality. I've parametrized (3) with a command for obtaining the spec file, for people who keep it on a remote machine etc. so obviously (2) should have a corresponding option. I suppose it could get it from periodic.conf but that's a bit ugly since it isn't a periodic script. Does anyone have any better ideas? I'd also like to optionally run (2) as part of the installworld process, and maybe include it as part of the standard distribution. I'm currently keeping the file in /var/db/; I'm not sure whether or not that's better than /etc/mtree/ -- it's over 7MB on my machine which is probably an important consideration. The patch to mtree and some of the scripts can be found at http://people.FreeBSD.org/~fanf/FreeBSD/ Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SOUTH FITZROY: WESTERLY VEERING NORTHWESTERLY 4 OR 5, OCCASIONALLY 6 AT FIRST. RAIN OR DRIZZLE AT TIMES. GOOD OCCASIONALLY MODERATE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Thread-safe resolver [patches for review]
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 to make gethostbyXXX(3) returning data placed into
per-thread storage when linked with libc_r. I like the latter approach
more, since it doesn't introduce new non-standard APIs.
I would like to hear any comments and suggestions on the proposed
patches, as well as to opinions about which path to chose.
Thanks!
-Maxim
Index: src/include/netdb.h
===
RCS file: /home/ncvs/src/include/netdb.h,v
retrieving revision 1.24
diff -d -u -r1.24 netdb.h
--- src/include/netdb.h 26 Jun 2002 08:18:42 - 1.24
+++ src/include/netdb.h 10 Aug 2002 10:03:43 -
@@ -82,7 +82,10 @@
#define_PATH_PROTOCOLS "/etc/protocols"
#define_PATH_SERVICES "/etc/services"
-extern int h_errno;
+__BEGIN_DECLS
+int * __h_errno_accessor(void);
+__END_DECLS
+#define h_errno (* __h_errno_accessor())
/*
* Structures returned by network data base library. All addresses are
@@ -240,6 +243,15 @@
char *gai_strerror(int);
void setnetgrent(const char *);
void setservent(int);
+
+intgethostbyaddr_r(const char *, int, int, struct hostent *,
+char *, int, int *);
+intgethostbyname_r(const char *, struct hostent *,
+char *, int, int *);
+intgethostbyname2_r(const char *, int, struct hostent *,
+ char *, int, int *);
+struct hostent *gethostent_r(struct hostent *, char *, int);
+
/*
* PRIVATE functions specific to the FreeBSD implementation
Index: src/include/resolv.h
===
RCS file: /home/ncvs/src/include/resolv.h,v
retrieving revision 1.21
diff -d -u -r1.21 resolv.h
--- src/include/resolv.h23 Mar 2002 17:24:53 - 1.21
+++ src/include/resolv.h10 Aug 2002 10:03:43 -
@@ -90,11 +90,16 @@
#defineMAXDFLSRCH 3 /* # default domain levels to try */
#defineMAXDNSRCH 6 /* max # domains in search path */
#defineLOCALDOMAINPARTS2 /* min levels in name that is "local"
*/
+#defineMAXALIASES 35 /* max # of aliases to return */
+#defineMAXADDRS35 /* max # of addresses to return */
#defineRES_TIMEOUT 5 /* min. seconds between retries */
#defineMAXRESOLVSORT 10 /* number of net to sort on */
#defineRES_MAXNDOTS15 /* should reflect bit field size */
+#defineCAST_ALIGN(ptr, type) \
+ (char*)(type)ptr < (char*)ptr ? ((type)ptr) + 1 : (type)ptr
+
struct __res_state {
int retrans;/* retransmition time interval */
int retry; /* number of times to retransmit */
@@ -198,10 +203,6 @@
char * humanname; /* Its fun name, like "mail exchanger" */
};
-extern struct __res_state _res;
-/* for INET6 */
-extern struct __res_state_ext _res_ext;
-
extern const struct res_sym __p_class_syms[];
extern const struct res_sym __p_type_syms[];
@@ -224,6 +225,7 @@
#definefp_query__fp_query
#definefp_nquery __fp_nquery
#definehostalias __hostalias
+#definehostalias_r __hostalias_r
#defineputlong __putlong
#defineputshort__putshort
#definep_class __p_class
@@ -273,6 +275,7 @@
void fp_query(const u_char *, FILE *);
void fp_nquery(const u_char *, int, FILE *);
const char * hostalias(const char *);
+const char * hostalias_r(const char *, char *, int);
void putlong(u_int32_t, u_char *);
void putshort(u_int16_t, u_char *);
const char * p_class(int);
@@ -315,5 +318,30 @@
void res_freeupdrec(ns_updrec *);
#endif
__END_DECLS
+
+struct __res_data {
+ int h_errno_res;
+ int s; /* socket used for communications */
+ int connected : 1; /* is the socket connected */
+ int vc : 1; /* is the socket a virtual circuit? */
+ int af; /* address family of socket */
+ res_send_qhook Qhook;
+ res_send_rhook Rhook;
+ FILE* hostf;
+ int stayopen;
+ struct __res_state *res;
+ struct __res_state_ext *res_ext;
+};
+
+__BEGIN_DECLS
+u_int16_t _getshort(const u_char *);
+u_int32_t _getlong(const u_char *);
+struct __res_data * __res_data_accessor(void);
+struct __res_state * __res_accessor(void);
+__END_DECLS
+#define _res_data (* __res_data_accessor())
+#define _res (* __res_accessor())
+/* for INET6 */
Re: Hi, how the kernel add the devices
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; /* skip dummy task(s)*/ if ((*sipp)->subsystem == SI_SUB_DONE) continue; /* Call function */ (*((*sipp)->func))((*sipp)->udata); /* Check off the one we're just done */ (*sipp)->subsystem = SI_SUB_DONE; /* Check if we've installed more sysinit items via KLD */ if (newsysinit != NULL) { if (sysinit != SET_BEGIN(sysinit_set))free(sysinit, M_TEMP); sysinit = newsysinit; sysinit_end = newsysinit_end; newsysinit = NULL; newsysinit_end = NULL; goto restart; } }Now, I am puzzled about the function pointer(func), which is how to work. For example, I have a NIC ¡®fxp0¡¯, so the function pointer should point to the fxp_attach?If that is right, I want to know how the kernel call the mi_startup()? Best Regards Ouyang Kai Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
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; /* skip dummy task(s)*/
if ((*sipp)->subsystem == SI_SUB_DONE)
continue;
/* Call function */
(*((*sipp)->func))((*sipp)->udata);
/* Check off the one we're just done */
(*sipp)->subsystem = SI_SUB_DONE;
/* Check if we've installed more sysinit items via KLD */
if (newsysinit != NULL) {
if (sysinit != SET_BEGIN(sysinit_set))
free(sysinit, M_TEMP);
sysinit = newsysinit;
sysinit_end = newsysinit_end;
newsysinit = NULL;
newsysinit_end = NULL;
goto restart;
}
}
Now, I am puzzled about the function pointer(func), which is how to work.
For example, I have a NIC ¡®fxp0¡¯, so the function pointer should point to the
fxp_attach?
Best Regards
Ouyang Kai
If that is right, I want to know how the kernel call the mi_startup()?
Re: Hi, how the kernel add the devices
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 message
Hi, how the kernel add the devices
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)(pdev->pdev_count);I know the NetBSD kernel add devices(such as storage device and network device) by them.But in FreeBSD, I can not locate the place.which part code should I read?Thank you. Best Regards Ouyang Kai Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
[no subject]
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)(pdev->pdev_count); I know the NetBSD kernel add devices(such as storage device and network device) by them. But in FreeBSD, I can not locate the place. which part code should I read? Thank you. Best Regards Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com
