Re: Newer pccard code
[[ I had observed that if_detach seemed to cause problems in the pccard code after the device had gone away. Redirected to -hackers since I think is where hairy network stuff is dealt with. --imp ]] In message <[EMAIL PROTECTED]> Atsushi Onoe writes: : There are some inconsistency of two TAILQs: : ifp->if_addrheadstruct ifaddr : in_ifaddrhead struct in_ifaddr : : Both these two list are managed in in_control (netinet/in.c). : In case of removing pccard, if_detach() only cares about ifp->if_addrhead, : and the corresponding in_ifaddr entry in in_ifaddrhead is not removed. : Since free'd ifaddr is still referenced by in_ifaddr, : it will be the reason of possible crash or lock up by looped list. : : I'm not sure how to fix this, but if_detach() should not remove : ifaddr from ifp->if_addrhead, and should ask protocol specific layer : to delete all addresses through if_ioctl(). SIOCFIFADDR? I'll leave this one to those more skilled at the network layer than I am. I don't know the network layer that well right now. I did observe that I didn't get any more crashes after disabling my use of DHCP to get an address. Likely that was the dangling reference that cause me grief. dhcp uses bpf, which is likely the reference in question. W/o dhcp, I was able to insert/remove the card 4 times w/o a problem, where before doing it twice would alway give a crash. The machine was stable enough to then make the commits to -current from, which never has been the case before. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Glide source available
On Tue, 7 Dec 1999, Doug Rabson wrote: > On Tue, 7 Dec 1999, Stephen Hocking-Senior Programmer PGS Perth wrote: > > > > > Go look at http://linux.3dfx.com/open_source > > It's availabe for Voodoo 1, 2, & 3 cards. Register level specs too! I'm > > utterly freaked out. > > Its pretty cool. I spent some time hacking the Voodoo2 sources today and I > ported both the glide2x and glide3x libraries. I managed to run all the > tests but haven't run anything substantial. Patches at: > > http://www.freebsd.org/~dfr/Glide-V2-2.53.diff > http://www.freebsd.org/~dfr/Glide-V2-3.01.diff > > If someone can take these and maybe roll them into a couple of ports, I > would be grateful. I just remembered that a couple of files are missing from the 3.01 diff. I'll regenerate that today. To build 2.53, you will need gasp. I added gasp to the build yesterday but I mucked it up. I'll fix that too shortly and you will be able to install gasp by 'make all install' in src/gnu/usr.bin/binutils followed by src/usr.bin/objformat (which I also forgot to commit). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF & putting inode at the front of a file
> The big benefits to locality of meta & file data are to allow > drive/driver caching to do sequential (or close to) reads in as large > blocks as possible. There was a recent SigOS paper on a modified Unix > filesystem that was designed to take advantage of modern disk systems, Do you still remember the title of that paper and tell me where can I find it (preferebly online)? -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: kstat - an API for gathering kernel stats
Is it possible to make nodes dynamically that are immutable from userland (even by root), but modifyable from the kernel? On Mon, 29 Nov 1999, Andrzej Bialecki wrote: > > Yes. See for example linux emulator or my SPY module: > > http://www.freebsd.org/~abial/spy > > You can also create whole new branches, as the second example shows. > > Andrzej Bialecki > > // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) > // --- > // -- FreeBSD: The Power to Serve. http://www.freebsd.org > // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ Dan Seguin Texar Software, Corporation. Visit us at the RSA Conference 2000, January 16-20, San Jose, Booth # 1241 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Upgrading rdist to v6.1.5 in -CURRENT?
On Tue, Dec 07, 1999 at 10:13:34PM -0500, C. Stephen Gunn wrote: > Since rdist 6.1.5 is back under a BSD Style license, should we work > towards updating it in -CURRENT, and perhaps -STABLE. It has several > bug fixes and enhancements to the current supplied rdist. Yaay. That's a good thing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Use of the ppi interface
Hi, I'm using the parallel port to control some sort of a hardware (i2c). For that I generate pulses using the ppi device (geek port). The problem is that in some cases, the pulse isn't generated. What I do is sending an ioctl to make the device high (1) and another ioctl to set the device low (0). It seems that in some cases, the two commands arrive together to the device so the pulse isn't wide enough. Does the ppbus layer stores the ioctl's in some sort of a buffer and than flushes its content to the hardware? If so, is there a way to control it? The pulses should be in fixed size, so any other idea will be welcomed. Thanx, ---Daniel Hilevich mailto:[EMAIL PROTECTED] Tel: +972-4-9592203 ext. 214Charlotte's Web Networks LTD. http://www.cwnt.com
Re: ELF & putting inode at the front of a file
> > > The big benefits to locality of meta & file data are to allow > > drive/driver caching to do sequential (or close to) reads in as large > > blocks as possible. There was a recent SigOS paper on a modified Unix > > filesystem that was designed to take advantage of modern disk systems, > > Do you still remember the title of that paper and tell me where can I find > it (preferebly online)? > > -Zhihui Author: Gregory R. Ganger Author: M. Frans Kaashoek Title: Embedded Inodes and Explicit Grouping: Exploiting Disk Bandwidth for Small Files Pages: 1-17 Publisher: USENIX Proceedings: 1997 Annual Technical Conference Date: January 6-10, 1997 Location: Anaheim, CA Institution: MIT available to usenix members in the online lirary at https://www.usenix.org//publications/publications.html. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: kstat - an API for gathering kernel stats
On Wed, 8 Dec 1999, Dan Seguin wrote: > > Is it possible to make nodes dynamically that are immutable from userland > (even by root), but modifyable from the kernel? Yes, of course. Just mark them as read-only (CTLFLAG_RD). You are free to assign any value to them within the kernel. If it's more complex type handled with SYSCTL_PROC (like eg. vm.zone sysctl) you still can decide what value you return from kernel, and you can ignore any requests to assign new values. > > On Mon, 29 Nov 1999, Andrzej Bialecki wrote: > > > > > Yes. See for example linux emulator or my SPY module: > > > > http://www.freebsd.org/~abial/spy > > > > You can also create whole new branches, as the second example shows. > > > > Andrzej Bialecki > > > > // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) > > // --- > > // -- FreeBSD: The Power to Serve. http://www.freebsd.org > > // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ > > > > > Dan SeguinTexar Software, Corporation. > > Visit us at the RSA Conference 2000, January 16-20, San Jose, Booth # 1241 > > > > Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: kstat - an API for gathering kernel stats
On Mon, Nov 29, 1999 at 10:09:35AM +0100, Andrzej Bialecki wrote:
> > I was thinking about implementing SMP cpu stats using sysctl today and
> > I have a question - can I create sysctl nodes dynamically ?
> >
> > i.e.
> >
> > for (cpu = 0; cpu < get_num_cpus(); cpu++) {
> > /* create sysctl node here ? */
> > }
>
> Yes. See for example linux emulator or my SPY module:
>
> http://www.freebsd.org/~abial/spy
>
> You can also create whole new branches, as the second example shows.
Thanks - that was useful. However, I noticed that only the leaves
(SYSCTL_INT/LONG/STRING) etc can be dynamically created. But nodes
can't be dynamically created. Am I correct ?
I'm interested in doing something like:
kern.stats.cpu0.idle
kern.stats.cpu0.nice
...
kern.stats.cpu1.idle
kern.stats.cpu1.nice
...
and I want the nodes cpu0, cpu1 etc dynamically created.
But that's no big deal. I'll define 4 cpus for now and zero the values for
non-existent cpus.
-Arun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: kstat - an API for gathering kernel stats
On Wed, 8 Dec 1999, Arun Sharma wrote:
> On Mon, Nov 29, 1999 at 10:09:35AM +0100, Andrzej Bialecki wrote:
> > > I was thinking about implementing SMP cpu stats using sysctl today and
> > > I have a question - can I create sysctl nodes dynamically ?
> > >
> > > i.e.
> > >
> > > for (cpu = 0; cpu < get_num_cpus(); cpu++) {
> > > /* create sysctl node here ? */
> > > }
> >
> > Yes. See for example linux emulator or my SPY module:
> >
> > http://www.freebsd.org/~abial/spy
> >
> > You can also create whole new branches, as the second example shows.
>
> Thanks - that was useful. However, I noticed that only the leaves
> (SYSCTL_INT/LONG/STRING) etc can be dynamically created. But nodes
> can't be dynamically created. Am I correct ?
Erhm.. No.
Look closer at the SPY module. I create the whole branch from the root
level. In the standard system there is no such thing as "kld" node,
neither there is a "spy" node. I created both of them. Only then I created
a bunch of leaves (of course, nothing stops you from creating some more
leaves on each intermediate level, if you need them).
The same is with linux emulator. It creates "compat" node, then
"linux" node, and then a couple of sysctls.
Andrzej Bialecki
// <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: kstat - an API for gathering kernel stats
On Wed, Dec 08, 1999 at 05:44:31PM +0100, Andrzej Bialecki wrote: > On Wed, 8 Dec 1999, Arun Sharma wrote: > Erhm.. No. > > Look closer at the SPY module. I create the whole branch from the root > level. In the standard system there is no such thing as "kld" node, > neither there is a "spy" node. I created both of them. Only then I created > a bunch of leaves (of course, nothing stops you from creating some more > leaves on each intermediate level, if you need them). Given a number N, whose value is determined at run time, could you have created N kld nodes ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Getting a new MAP_ flag into mmap() prior to 4.x freeze
I would like to add a new MAP_ flag to mmap() prior to the 4.x freeze. The purpose of the flag is to prevent the syncer from syncing the file underlying the map. The VM system will still page to the file as needed and, of course, the data will remain consistent with the file. This will allow normal files to be used to back (for example) shared memory without incuring the extra overhead that sync causes every 30 seconds. Currently it is not possible to use normal files in this fashion (verses using MAP_ANON, for which sharability is limited, or SysV shared memory which often has unexpected limitations) and still have an efficient system. The flag will be called MAP_NOSYNC Operationally, the syncer will not sync the file while any mmap()'s exist with that flag set. Once such flagged maps go away, the syncer will be able to sync the file (if it still exists). Comments are welcome. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Upgrading rdist to v6.1.5 in -CURRENT?
On Thu, Dec 09, 1999 at 04:00:17AM +1300, Joe Abley wrote: > Yaay. That's a good thing. There had been some discussion and concern about the protocol incompatabilies. There was even some discussion if rdist was needed in the base system any more. It would still be available as a port. There are alternatives (rsync), but I still don't think they fill rdist's shoes for complex, or even some simple (dependant on your experience with rdist) tasks: ( /etc/aliases ) -> ( alpha beta gamma cosmic ) install /etc/aliases; special "/usr/sbin/newaliases"; I think you'd need a wrapper to do this successfully with rsync, which really is a lot more work than writing a Distfile. - Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze
On Wed, 8 Dec 1999, Matthew Dillon wrote: > Operationally, the syncer will not sync the file while any mmap()'s > exist with that flag set. Once such flagged maps go away, the syncer > will be able to sync the file (if it still exists). > > Comments are welcome. I assume that this flag would require write permission to the file, to prevent bad security implications? -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Faster Malloc
http://www.cs.utexas.edu/users/emery/hoard/ Only Linux,Solaris,IRIX,NT, and BeOS supported at this stage. Anyone wants to port it to FreeBSD? Sorry if everyone knows this already... Rayson __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze
:I assume that this flag would require write permission to the file, to :prevent bad security implications? : :-- : Ben Rosengart You can set the flag without write permission but it will not do anything in that case. The only way to get a page marked such that the syncer doesn't sync it is if you mmap() an area of memory and then take write-faults on pages within that area, which requires write permission to succeed. Only pages dirtied through a mmap marked to not sync will not sync. Things like file meta-data always sync, though if the only data written to a file is through such an mmap() the filesystem will not have much to do there. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: kstat - an API for gathering kernel stats
On Wed, 8 Dec 1999, Arun Sharma wrote: > I'm interested in doing something like: > > kern.stats.cpu0.idle > kern.stats.cpu0.nice > ... > kern.stats.cpu1.idle > kern.stats.cpu1.nice > ... > > and I want the nodes cpu0, cpu1 etc dynamically created. It would be better to have kern.stats.nice.cpu0 kern.stats.nice.cpu1 or simply kern.stats.nice.0 -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Faster Malloc
>From the web page: "Hoard is a fast, scalable and memory-efficient allocator for multiprocessors. Hoard solves the heap contention problem caused when multiple threads call dynamic memory allocation functions like malloc() and free() (or new and delete). Hoard can dramatically improve the performance of multithreaded programs running on multiprocessors." It doesn't sound like it would help much under the current FreeBSD pthread implementation, because userland threads shouldn't suffer from multiprocessor contention. Later, scott - Original Message - From: Rayson Ho <[EMAIL PROTECTED]> To: List <[EMAIL PROTECTED]> Sent: Wednesday, December 08, 1999 10:09 AM Subject: Faster Malloc > > http://www.cs.utexas.edu/users/emery/hoard/ > > Only Linux,Solaris,IRIX,NT, and BeOS supported at this > stage. Anyone wants to port it to FreeBSD? > > Sorry if everyone knows this already... > > > Rayson > > > > > __ > Do You Yahoo!? > Thousands of Stores. Millions of Products. All in one place. > Yahoo! Shopping: http://shopping.yahoo.com > > > 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
Interrupt handler for PCI
This message was sent from Geocrawler.com by "Alex" <[EMAIL PROTECTED]> Be sure to reply to that address. Hello, I'm writting driver for PCI board. Is't possible to set interrupt handler for PCI device not in attach function? If yes, how? For ISA is possible to do by calling reconfig_isadev(dev, &imask) for one device. Thank you Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Faster Malloc
It might be nice when LWP support is added. -Kip On Wed, 8 Dec 1999, Scott Hess wrote: > From the web page: > > "Hoard is a fast, scalable and memory-efficient allocator for > multiprocessors. Hoard solves the heap contention problem caused when > multiple threads call dynamic memory allocation functions like malloc() and > free() (or new and delete). Hoard can dramatically improve the performance > of multithreaded programs running on multiprocessors." > > It doesn't sound like it would help much under the current FreeBSD pthread > implementation, because userland threads shouldn't suffer from > multiprocessor contention. > > Later, > scott > > - Original Message - > From: Rayson Ho <[EMAIL PROTECTED]> > To: List <[EMAIL PROTECTED]> > Sent: Wednesday, December 08, 1999 10:09 AM > Subject: Faster Malloc > > > > > > http://www.cs.utexas.edu/users/emery/hoard/ > > > > Only Linux,Solaris,IRIX,NT, and BeOS supported at this > > stage. Anyone wants to port it to FreeBSD? > > > > Sorry if everyone knows this already... > > > > > > Rayson > > > > > > > > > > __ > > Do You Yahoo!? > > Thousands of Stores. Millions of Products. All in one place. > > Yahoo! Shopping: http://shopping.yahoo.com > > > > > > 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 > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: kstat - an API for gathering kernel stats
> On Wed, 8 Dec 1999, Arun Sharma wrote: > > I'm interested in doing something like: > > > > kern.stats.cpu0.idle > > kern.stats.cpu0.nice > > ... > > kern.stats.cpu1.idle > > kern.stats.cpu1.nice > > ... > > > > and I want the nodes cpu0, cpu1 etc dynamically created. > > It would be better to have > > kern.stats.nice.cpu0 > kern.stats.nice.cpu1 > > or simply > > kern.stats.nice.0 Yes, please! It would be helpful if the kernel's MIB used instances (and there was easy support for creating them) like the MIBs many of us use SNMP to access in network elements. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Faster Malloc
On Wed, 8 Dec 1999, Kip Macy wrote: > > From: Rayson Ho <[EMAIL PROTECTED]> > > > > > > http://www.cs.utexas.edu/users/emery/hoard/ > > > > > > Only Linux,Solaris,IRIX,NT, and BeOS supported at this > > > stage. Anyone wants to port it to FreeBSD? > > > > > > Sorry if everyone knows this already... > > > > On Wed, 8 Dec 1999, Scott Hess wrote: > > > From the web page: > > > > "Hoard is a fast, scalable and memory-efficient allocator for > > multiprocessors. Hoard solves the heap contention problem caused when > > multiple threads call dynamic memory allocation functions like malloc() and > > free() (or new and delete). Hoard can dramatically improve the performance > > of multithreaded programs running on multiprocessors." > > > > It doesn't sound like it would help much under the current FreeBSD pthread > > implementation, because userland threads shouldn't suffer from > > multiprocessor contention. > > It might be nice when LWP support is added. > > -Kip Userland threads can contend against themselves, right now the kernel doesn't but it would be a good thing to implement for later use. We also support shared address space fork, so this may be a good idea for programs that utilize that. This allocator is pretty much what the Dynix allocator is, it wouldn't be difficult to clean-room implement this with a BSD license. They should have given credit to Dynix or at least Uresh Vahalia (discussed on page 390 of his book Unix Internals section 12.9). -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze
On Wed, 8 Dec 1999, Matthew Dillon wrote: > I would like to add a new MAP_ flag to mmap() prior to the 4.x freeze. > The purpose of the flag is to prevent the syncer from syncing the > file underlying the map. The VM system will still page to the file as > needed and, of course, the data will remain consistent with the file. > > This will allow normal files to be used to back (for example) shared > memory without incuring the extra overhead that sync causes every 30 > seconds. Currently it is not possible to use normal files in this > fashion (verses using MAP_ANON, for which sharability is limited, or > SysV shared memory which often has unexpected limitations) and still > have an efficient system. > > The flag will be called MAP_NOSYNC > > Operationally, the syncer will not sync the file while any mmap()'s > exist with that flag set. Once such flagged maps go away, the syncer > will be able to sync the file (if it still exists). > > Comments are welcome. I'd like to see this happen, go for it! :) Don't forget how getnewbuf refils the buffers though, it will need to somehow to communicate to the syncer to disregard MAP_NOSYNC during a shortage... ? :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze
:I'd like to see this happen, go for it! :) : :Don't forget how getnewbuf refils the buffers though, it will need to :somehow to communicate to the syncer to disregard MAP_NOSYNC during a :shortage... ? :) : :-Alfred No, I don't bother with that. If there is a filesystem buffer associated with a dirty page the NOSYNC is ignored. The only time a filesystem buffer can be associated with a NOSYNC page is if you write(). In that case we allow the normal filesystem mechanisms to handle it. The tie-in is really trivial -- there is essentially one procedure which the object code calls to synchronize a range and it is comprised of two parts: Collecting dirty pages and constructing filesystem buffers for them, and flushing out filesystem buffers. NOSYNC simply prevents the first part from occuring for normal asynchronous flushes. The second part thus nevers sees the pages unless some other command indirectly associates them with a buffer -- like write() does for example. For low-memory situations we let the pagedaemon handle things. The pagedaemon ignores the NOSYNC flag. That is, NOSYNC space is treated just the same as swap-backed memory is treated - pageed only when necessary. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mmap() and atime/mtime
Matthew Dillon wrote: > Things like file meta-data always sync, though if the only data written > to a file is through such an mmap() the filesystem will not have much > to do there. Incidentally, I notice that files "read" through a mmap (PROT_READ, MAP_SHARED) don't cause the file's atime to be set, on 3.3-STABLE and 2.2.8-STABLE at least. This doesn't strike me as the right thing to do, even if the stat(2) man page says: st_atimeTime when file data last accessed. Changed by the mknod(2), utimes(2) and read(2) system calls. >From a quick test, it does seem that "writing" through mmap does cause mtime to be set, despite stat(2) saying: st_mtimeTime when file data last modified. Changed by the mknod(2), utimes(2) and write(2) system calls. Good, other incremental backup systems might not work properly. However I do notice that the modification time isn't set until a short time after process exit (with an implied munmap & close), presumably by the syncer. However we do have the somewhat strange situation that atime < mtime. The Open Group Single UNIX Specification Version 2 says in: http://www.opengroup.org/onlinepubs/007908799/xsh/mmap.html "The st_atime field of the mapped file may be marked for update at any time between the mmap() call and the corresponding munmap() call. The initial read or write reference to a mapped region will cause the file's st_atime field to be marked for update if it has not already been marked for update. The st_ctime and st_mtime fields of a file that is mapped with MAP_SHARED and PROT_WRITE, will be marked for update at some point in the interval between a write reference to the mapped region and the next call to msync() with MS_ASYNC or MS_SYNC for that portion of the file by any process. If there is no such call, these fields may be marked for update at any time after a write reference if the underlying file is modified as a result." So it looks likely the commercial Unix's set atime. From a quick test it looks like Linux does as well. Seems to me FreeBSD should do the same. I'm inclined to the view that it would be nice if mtime was set at the first write reference that would change the underlying object, but not synced out to disk at that time. This means running processes do at least see the mtime change immediately, just as they'd see the changes if they mmap'd the file. Richard -- Richard Wendland[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze
: : :I think that you imply explicit msync() calls still flush data to disk. Is :that the case? : :Jason Young :accessUS Chief Network Engineer msync never guarenteed the flushing of data to disk, it simply guarentees synchronization with the buffer cache. FreeBSD, however, uses a coherent VM/buffer-cache. The FreeBSD msync with the MS_SYNC flag appears to flush VM data to physical media, though in my test it is terribly slow (it doesn't cluster!). msync doesn't care whether the pages are NOSYNC or not. i.e. NOSYNC has no effect on the operation of msync(). msync() with the MS_ASYNC flag appears to cluster properly. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New mpd with netgraph and PPTP
A new version of 'mpd', a multi-link PPP daemon, is available as a beta release from Whistle Communications under the Whistle license (BSD style). * This new version is completely netgraph(4) based, which means that all of the negotiation protocols (IPCP, LCP, etc) are handled in user-land, while all data transmission, compression, encryption, etc. is handled strictly in the kernel. This approach combines the configuration flexibility of a user-mode PPP daemon with the speed of a kernel-only PPP daemon, not to mention the wide device type and protocol support of netgraph. * This version also includes support for the Point-to-Point Tunneling Protocol (PPTP), in both client "dial-in" mode and LAN-LAN VPN, and is compatible with Microsoft's Dial-Up Networking VPN adapter. To get the new mpd: 1. Update your -stable or -current system from CVS (ie, today's!) and make world (or at least build and install a new kernel, kernel includes, netgraph modules, and libnetgraph). 2. Run pkg_delete on any existing mpd port on your machine 3. Blow away /usr/ports/net/mpd, and replace it with this: ftp://ftp.whistle.com/pub/archie/mpd/port.tgz 4. Build and install the new port. Any bug reports, suggestions, etc. are greatly appreciated. I'd also be interested to hear if anyone does any speed comparisions between this version of mpd and other FreeBSD PPP implementations. Cheers, -Archie PS: We also have an MPPE (Microsoft Point-to-Point encryption) implementation (as a netgraph module). This allows Microsoft clients' PPTP connections to be encrypted, though the security of MPPE is not very strong. However, it includes RC4, which is patented, so you must get your own implementation of RC4 (legally!) and compile the node yourself. Let me know by email if you're interested in trying this out too. PPS: Does not understand PPPoE yet.. use 'ppp' for that. ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting a new MAP_ flag into mmap() prior to 4.x freeze
I think that you imply explicit msync() calls still flush data to disk. Is that the case? Jason Young accessUS Chief Network Engineer On Wed, 8 Dec 1999, Matthew Dillon wrote: > :I'd like to see this happen, go for it! :) > : > :Don't forget how getnewbuf refils the buffers though, it will need to > :somehow to communicate to the syncer to disregard MAP_NOSYNC during a > :shortage... ? :) > : > :-Alfred > > No, I don't bother with that. If there is a filesystem buffer associated > with a dirty page the NOSYNC is ignored. The only time a filesystem > buffer can be associated with a NOSYNC page is if you write(). In that > case we allow the normal filesystem mechanisms to handle it. > > The tie-in is really trivial -- there is essentially one procedure which > the object code calls to synchronize a range and it is comprised of two > parts: Collecting dirty pages and constructing filesystem buffers > for them, and flushing out filesystem buffers. > > NOSYNC simply prevents the first part from occuring for normal > asynchronous flushes. The second part thus nevers sees the pages unless > some other command indirectly associates them with a buffer -- like write() > does for example. > > For low-memory situations we let the pagedaemon handle things. The > pagedaemon ignores the NOSYNC flag. That is, NOSYNC space is treated > just the same as swap-backed memory is treated - pageed only when > necessary. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > > > 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: Getting a new MAP_ flag into mmap() prior to 4.x freeze
good flag. If you look at my old mnfs stuff you can see our solution : we ignored sync :-) This is a good move. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap() and atime/mtime
:Matthew Dillon wrote: : :> Things like file meta-data always sync, though if the only data written :> to a file is through such an mmap() the filesystem will not have much :> to do there. : :Incidentally, I notice that files "read" through a mmap (PROT_READ, :MAP_SHARED) don't cause the file's atime to be set, on 3.3-STABLE :and 2.2.8-STABLE at least. : :This doesn't strike me as the right thing to do, even if the stat(2) man :page says: I think you're right, but it isn't something that I can fix this second. I recommend filing a PR and then emailing me the PR number. I'll assign it to myself so it shows up in my weekly reminder but I don't think I'm going to get to it for a couple of months. :I'm inclined to the view that it would be nice if mtime was set at :the first write reference that would change the underlying object, :but not synced out to disk at that time. This means running :processes do at least see the mtime change immediately, just as :they'd see the changes if they mmap'd the file. : : Richard :-- :Richard Wendland [EMAIL PROTECTED] I would hesitate to delve that deeply into the VFS system from a VM fault for performance reasons. The Open Group specification you quoted seems reasonable to me, but the mtime specification is not 100% achieveable % in a coherent VM/buffer-cache because once the page is dirtied the process can make further modifications to it (that essentially modify the underlying file) without any further faulting. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing to an mmap()'ed region requires read access?
:
: Shouldn't the mmap() return MAP_FAILED, probably with EACCES,
:instead of causing a signal 10?
:
:--
:Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
It's one of those cases that occurs when you have a general purpose
call where the mix of arguments is not expected to be used. I'm not
sure 'fixing' it would accomplish anything in real terms.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ctype.h difines _T globaly
I propose that ctype.h not define _T, but instead define _CTYPE_T. Other two letter macros also should be changed likewise. Definition of such macro by the system are perhaps allowed by the standard, but its better not to define such macros. One reason is that the STL code included in stdlibc++ currently uses _T as local identifier. This code will be broken by the macro in ctype.h. To change the situation one can change the c++ codes. Another way is to change the macro in ctype.h. Both action can be taken at the same time. The other reason is that it is not good to polute the global namespace by just a part of the system. One does not expect that _T is defined in ctype.h. But if the macro were _CTYPE_T it is easier to come to the idea that it might be defined in ctype.h. -- Tomoaki Nishiyama e-mail:[EMAIL PROTECTED] Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mmap/write case brought up again - maybe its time to...
Someone brought up the mmap/write case up again - that's a deadlock case that we haven't fixed yet where you write from one descriptor into shared writeable file-backed memory area and, from another process, do the vise-versa. Maybe it's time to make filesystem locks recursive by default. Doing so will allow the above case to be fixed 100% by allowing the read() and write() code to pre-lock the underlying vnodes in the correct order (by pointer comparison) prior to digging into them. I think Kirk may be the best person to make this determination - I seem to recall there being some (minor?) issues. Implementing recursive locks may be as simple as adding LK_RECURSE to vn_lock() but I haven't researched it heavily. This may also tie-in well with the revamping of the VOP code later on. There is a significant amount of complexity in the VOP code in having to deal with non-recursive locks when a passed argument is supposed to be locked and remain locked on return, the return argument is supposed to be locked, and the returned argument winds up being the same as the passed argument. With recursive locks as the norm we can remove nearly all of those special cases leaving just the one that deals with ".." (or perhaps dealing with namei directory locks in a different way). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap/write case brought up again - maybe its time to...
Date: Wed, 8 Dec 1999 21:30:37 -0800 (PST) From: Matthew Dillon <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Kirk McKusick <[EMAIL PROTECTED]> Subject: mmap/write case brought up again - maybe its time to... Someone brought up the mmap/write case up again - that's a deadlock case that we haven't fixed yet where you write from one descriptor into shared writeable file-backed memory area and, from another process, do the vise-versa. Maybe it's time to make filesystem locks recursive by default. Doing so will allow the above case to be fixed 100% by allowing the read() and write() code to pre-lock the underlying vnodes in the correct order (by pointer comparison) prior to digging into them. I think Kirk may be the best person to make this determination - I seem to recall there being some (minor?) issues. Implementing recursive locks may be as simple as adding LK_RECURSE to vn_lock() but I haven't researched it heavily. This may also tie-in well with the revamping of the VOP code later on. There is a significant amount of complexity in the VOP code in having to deal with non-recursive locks when a passed argument is supposed to be locked and remain locked on return, the return argument is supposed to be locked, and the returned argument winds up being the same as the passed argument. With recursive locks as the norm we can remove nearly all of those special cases leaving just the one that deals with ".." (or perhaps dealing with namei directory locks in a different way). -Matt Recursive locks are easy to implement. Just add LK_CANRECURSE as the final argument to the call to lockinit at line 1077 in ffs_vget of ufs/ffs/ffs_vfsops.c. That's it. From there on out all FFS locks will be recursive and you can begin simplifying away. Kirk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
question about boot loaders
The documentation in /usr/src/sys/boot/i386 seems a little scant, and that still hanging out in /usr/src/sys/i386/boot is clearly outdated. Was wondering if someone could point me at docs, and/or post a short summary something in the form of: loader loadedbyfunction mbr BIOSwhatever, maybe a couple of lines boot0 ??? "" ""... boot1 ??? "" ""... boot2 boot1 FreeBSD bootloader that speaks protected mode, etc, and can load the kernel around gaps in physical memory, etc. loader boot2 Forth interpreter + scripting for great fun kernel loader or boot2 The kernel Once we get into boot2 land, I recognize the FreeBSD-specific loading code, etc. What I don't know much about is those first three 512-byte chunks of code. Boot0 appears to be booteasy, but given some ignorance about the i386 boot process, I'm not sure whether it's loaded by mbr, or by the bios, and where it lives partition-wise. Similarly, how boot1 fits into it the whole scheme--I assume this is FreeBSD-specific as it knows about boot2, but don't know where it lives, etc. Preferably, afterwards, also drop the results into sys/boot/i386/README. :-) Thanks, Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
