bios timecounter in doscmd
Hello,
As I found, I have overlooked a routine updating bios 0x6c 0x70
fields.
It is in function video_update (module tty.c):
*(u_long *)BIOSDATA[0x6c] += 1;/* Timer ticks since
midnight... */
while (*(u_long *)BIOSDATA[0x6c] = 24*60*6*182)
{
*(u_long *)BIOSDATA[0x6c] -=
24*60*6*182;
BIOSDATA[0x70]++; /* BIOSDATA[0x70] #
times p
}
The problem with this code is that it works only if (!booting). I do
not see the reason for such a restriction. I would suggest to move it to
int08 routine in timer.c in replacement to what is suggested in my
previous message, since this this routine also increments field 0x70.
Thanks,
Igor.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
ypserv (fixed... I think)
To those of us experiencing problems with ypserv, I have made a copy of my binary available at: DO NOT READ ANY FURTHER IF YOU HAVE NOT SETUP AND ADMINED A NIS DOMAIN! THIS IS NOT FOR YOU! http://www.cs.rpi.edu/~crossd/FreeBSD/ypserv MD5 (ypserv) = 1f1c6c01eafd690059b32e615e5b6efc It is binary only at this point primarily due to license issues (I borrowed heavily from BDB in my rewrite, and I have not credited things yet. This code represents the following changes: 1) Fix of a bug in librpc. 2) Fix of some race-conditions in ypserv 3) rewrite of libdb/hash I would like people to download it and give it a whirl. I would recommend the following actions for people wishing to try the code: 1) get a dump of all of your existing ypmaps, for all domains (if you have multiple) via ypcat -k MAPNAME. you can see all of your maps in /var/yp/DOMAIN/map 2) Get the start-time, CPU usage, size, RSS, etc of your current ypserv process... save this 3) mv /usr/sbin/ypserv /usr/sbin/ypserv.orig.. cp NEWYPSERV /usr/sbin... killall ypserv, /usr/sbin/ypserv -FLAGS, rm /ypserv.core, (see previous ypserv information, or consult /etc/rc.conf, /etc/defaults/rc.conf) 4) get a ypcat -k MAPNAME again.. compare the output of this to the previous ypserv. if there are _any_ differences (including order of output of the keys, LET ME KNOW. 5) write a script to pull the first word from the previously saved dump-files (cut -d -f 1) -- works for my maps, feed this into 'ypmatch -k $field MAPNAME anothersavefile' this should also be IDENTICAL to the 'ypcat -k' in the previous example. 6) At some future date (after this ypserv has been running about as long as the 'original' ypserv, get its information (Size, RSS, CPU, etc) and compare them, I am curious. 7) Verify there is no /ypserv.core, ever again. 8) I cannot stress heavily enough, this is for people willing to experiment with their systems, if you don't understand NIS, DON'T DO THIS! -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: _sigprocmask in malloc.c causes full file table?
On Sun, Aug 12, 2001 at 10:29:53AM -0400, Daniel Eischen wrote: sigprocmask() behaves the same as pthread_sigmask(). pthread_sigmask() needs to obtain the current thread. In obtaining the current thread, the threads library must be initialized. In initializing the threads library malloc() is called. Wash, rinse, repeat. We have a winner. This is the top of the (very long) call stack from the mozilla core file (which I admittedly should have examined earlier): #11913 0x2863ebda in _thread_init () from /usr/lib/libc_r.so.5 #11914 0x2863e7a3 in _get_curthread () from /usr/lib/libc_r.so.5 #11915 0x28633539 in pthread_sigmask () from /usr/lib/libc_r.so.5 #11916 0x2863f250 in sigprocmask () from /usr/lib/libc_r.so.5 #11917 0x286c9db5 in malloc () from /usr/lib/libc.so.5 #11918 0x2863a980 in _pq_alloc () from /usr/lib/libc_r.so.5 #11919 0x2863ebda in _thread_init () from /usr/lib/libc_r.so.5 #11920 0x2863e7a3 in _get_curthread () from /usr/lib/libc_r.so.5 #11921 0x28633539 in pthread_sigmask () from /usr/lib/libc_r.so.5 #11922 0x2863f250 in sigprocmask () from /usr/lib/libc_r.so.5 #11923 0x286c9db5 in malloc () from /usr/lib/libc.so.5 #11924 0x2863a980 in _pq_alloc () from /usr/lib/libc_r.so.5 #11925 0x2863ebda in _thread_init () from /usr/lib/libc_r.so.5 #11926 0x2863c063 in pthread_mutex_lock () from /usr/lib/libc_r.so.5 #11927 0x2861556d in __register_frame_info () from /usr/lib/libstdc++.so.3 #11928 0x28662fa2 in _init () from /usr/lib/libc.so.5 #11929 0x2866062d in _init () from /usr/lib/libc.so.5 #11930 0x2806de10 in _rtld () from /usr/libexec/ld-elf.so.1 So, in answer to the question, am I doing something boneheaded, or is this an undocumented subtle interaction, I'll give partial credit to both. Thank you very much for your assistance. -Michael Robinson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: the =+ operator
John Merryweather Cooper wrote: Prototypes are an overwhelmingly Good Thing(tm) as behind-your-back implicit parameter conversion is death to serious numerical work. At least now, some control can be exercised over parameter conversions . . . Who ever said anything about not being able to do that in Terry's view? You are taking one statement and running wildly with it. In my view, he was advocating chucking ANSI-89 and returning to the wild days of KR. I think that would be very bad. Clearly, you disagree with my understanding. Not my intent; I'm well known to dislike many of the decisions that the X3J11 committe made; in comp.lang.c, there was a long firefight, which only ended after [EMAIL PROTECTED] came down on my side of the argument and said: Let me begin by saying that I'm not convinced that even the pre-December qualifiers (`const' and `volatile') carry their weight; I suspect that what they add to the cost of learning and using the language is not repaid in greater expressiveness. `Volatile', in particular, is a frill for esoteric applications, and much better expressed by other means. Its chief virtue is that nearly everyone can forget about it. `Const' is simultaneously more useful and more obtrusive; you can't avoid learning about it, because of its presence in the library interface. Nevertheless, I don't argue for the extirpation of qualifiers, if only because it is too late. The fundamental problem is that it is not possible to write real programs using the X3J11 definition of C. The committee has created an unreal language that no one can or will actually use. While the problems of `const' may owe to careless drafting of the specification, `noalias' is an altogether mistaken notion, and must not survive. See http://www.lysator.liu.se/c/dmr-on-noalias.html for the full text of his posting. He also has a couple of choice words on prototypes requiring themselves. In benchmarking IBM's VisualAge C++ (Version 4.0), this seems to be the case, at least for me. I chose this compiler because it is easy, with the tools available for me to monitor the stages of compilation since each stage has a separate DLL. Using SciTech's MGL 5.0 Beta 2 Library, it is clear that Lexing/pre-processing take up the lion's share of the time. Obviously, your mileage differs. I would like to have your understanding of what's happening--and not this troll-mine. What's happeneing is that compiler users outnumber compiler writers, 100,000 to 1. Ergo, if a compiler writer can make a change that saves 1 hour of user time, he has saved 100,000 hours or user time. That is over 11 man years. Clearly, all tradeoffs should be made in favor of compiler users, not in favor of compiler writers, for the betterment of mankind. I know it's ambiguous. In fact, I think it's the most poorly standardized/described language to date. However, since C++ is quite popular, apparently my opinion doesn't carry much weight. :) The popularity of C++ was one of the driving factors behind the inclusion of prototypes. Even using symbol decoration, the approach used by both GCC and Microsoft Visual C++, there is enough information present for parameter errors to be identified and corrected at link time. The problem at the time, however, is that there was a race between Microsoft and Borland to have the fastest compiler; not that this doesn't mean the compiler that puts out the fastest code or the compiler that makes the jobs done by the programmers who use it take the shortest amount of time. So we got standardization of a language in which there were exposed bolts like volatile and const, which make the compiler writer's job (defined as compiling fast) easier, since barring these keywords, they were allowed to make assumptions that broke previously working code. From the reading I've done, I believe this conclusion is justified. Doubtless there are other opinions though . . . The C Programming Language Brian W. Kernighan, Dennis M. Ritchie Prentice-Hall ISBN: 0-13-110163-3 P. 212: 17. Anachronisms Since C is an evolving language, certain obsolete constructions may be found in older programs. Although most versions of the compiler support such anachronisms, ultimately they will disappear, leaving only a portability problem behind. Earlier versions of C used the form =op instead of op= for assignment operators. This leads to ambiguities, typified by x=-1 Which actually decerments x since the = and the - are adjacent, but which might easily be intended to assign -1 to x. The syntax of initializers has changed: previously, the equals sign that introduces an
Re: can't generate vnode_if.h automatically
Rohit Grover wrote: On Sun, 12 Aug 2001, Dima Dorfman wrote: Rohit Grover [EMAIL PROTECTED] writes: Interestingly, when I executed the command 'make depend', vnode_if.h was correctly created for me. I'd like to know why I don't need to do a 'make depend' for modules like 'vn' or 'nfs' before building them. Perhaps because it was done before? Check to see if you have a '.depend' file in those directories. I'm pretty sure you do. I did not find a .depend in sys/modules/vn. It's because of the order of declaration of the variables containing the source and the objects vs. the .include directive(s) in your Makefile. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mtio questions
On Sun, Aug 12, 2001 at 11:46:57AM -0700, Terry Lambert wrote: Bernd Walter wrote: Another point: Can we '#define MTEOM MTEOD' as MTEOM is used on NetBSD and Solaris? End of Message is not the same as End of Data for some drives; this could break old 8-track (no, not the music, and not a typeo for 9-track!) drives, e.g. Zilog and Cypher. Well that's what Solaris 8 sys/mtio.h tells about MTEOM: #define MTEOM 10 /* position to end of media */ And here NetBSD 1.5: #define MTEOM 10 /* forward to end of media */ Neither of them is saying Message. On Sun, Aug 12, 2001 at 06:03:00PM -0700, Matthew Jacob wrote: On Sun, 12 Aug 2001, Bernd Walter wrote: Another point: Can we '#define MTEOM MTEOD' as MTEOM is used on NetBSD and Solaris? Why? Please correct me if I'm wrong: If I want to append to a tape I would MTEOM on Solaris and MTEOD on FreeBSD so it's supposed to be used for the same reason. None of the OS I looked into had both. But well - that's what HP-UX define: #define MTEOD 8 /* DDS, QIC and 8MM only - seek to end-of-data */ -- 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: diskless
hi, i modified rc.diskless1 to use union fs like: mount_md 1024 /conf/etc 0 mount -t union /conf/etc /etc any reason why this might be problematic? not sure, i think i tried this at some point and had problems with bugs in the implementation of mount_union. If it works for you then i guess it is not problematic. One thing you cannot do with the above is delete files which are in the lower filesystem (not that the current rc.diskless1 does, but in principle you might want to do this). the solution currently in rc.diskless1 actually does a merge of 2-3 different filesystems, so between the mounts you have to populate /conf/etc as well. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: diskless
not sure, i think i tried this at some point and had problems with bugs in the implementation of mount_union. If it works for you then i guess it is not problematic. One thing you cannot do with the above is delete files which are in the lower filesystem (not that the current rc.diskless1 does, but in principle you might want to do this). so far rc.diskless1 only populates, so removing is not a problem. the solution currently in rc.diskless1 actually does a merge of 2-3 different filesystems, so between the mounts you have to populate /conf/etc as well. that's why im using /etc and not /conf/etc, it was becoming to complicated having more than one /etc. the nice thing is that i can use the same root for non diskless too. cheers luigi chiao danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mtio questions
Bernd Walter wrote: On Sun, Aug 12, 2001 at 11:46:57AM -0700, Terry Lambert wrote: Bernd Walter wrote: Another point: Can we '#define MTEOM MTEOD' as MTEOM is used on NetBSD and Solaris? End of Message is not the same as End of Data for some drives; this could break old 8-track (no, not the music, and not a typeo for 9-track!) drives, e.g. Zilog and Cypher. Well that's what Solaris 8 sys/mtio.h tells about MTEOM: #define MTEOM 10 /* position to end of media */ And here NetBSD 1.5: #define MTEOM 10 /* forward to end of media */ Neither of them is saying Message. I was thinking Media, but wrote Message, since that's what the ASCII characer EOM means; my bad. The end of the media can be interpreted as after the first EOF, before the second, in order to permit the tape volume to be extended. It can also be interpreted to mean before the first of two EOFs, such that the last extent can be extended. It's really hardware dependent, and ambiguous. Please correct me if I'm wrong: If I want to append to a tape I would MTEOM on Solaris and MTEOD on FreeBSD so it's supposed to be used for the same reason. None of the OS I looked into had both. But well - that's what HP-UX define: #define MTEOD 8 /* DDS, QIC and 8MM only - seek to end-of-data */ These devices are not absolutely positionable to EOM; they leave you after the last data block; on QIC, which records like: ---. ,---+--. `---' | -' It's nearly impossible to position to an exact location. DEC MT-50, MT-75, and 9-Track drives, on the other hand, were abosolutely positionable, and often were written with a real filesystem on them (FILES-11 format instead of ANSI format). You are delving into an area where things vary widely by vendor and the crossproduct of drivers and hardware... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: can't generate vnode_if.h automatically
Essentially, you should compile this module in the modules directory of the kernel source. This will solve your problems in the easiest manner. sorry for short answer.. driving all night back from HAL sleep. andrew On Sun, 12 Aug 2001, Rohit Grover wrote: :Hello, : :I am writing a module which needs to include 'sys/vnode.h'. vnode.h :tries to include vnode_if.h. I checked the Makefiles of some other :modules requiring vnode.h (eg. 'vn', 'nfs') and discovered that they :add vnode_if.h to to the variable 'SRCS'. This automagically generates :vnode_if.h in the current directory while running make for these :modules. : :I copied the makefile from one of these modules and changed 'SRCS' to :point to my sources. 'vnode_if.h' was included in 'SRCS' in my :makefile too. Unfortunately, this did not work for me. vnode_if.h was :not generated before compiling my sources and therefore my build :failed. : :Interestingly, when I executed the command 'make depend', :vnode_if.h was correctly created for me. I'd like to know why I don't :need to do a 'make depend' for modules like 'vn' or 'nfs' before :building them. : :regards, :Rohit. : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-hackers in the body of the message : *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: diskless
Danny Braniss wrote: not sure, i think i tried this at some point and had problems with bugs in the implementation of mount_union. If it works for you then i guess it is not problematic. One thing you cannot do with the above is delete files which are in the lower filesystem (not that the current rc.diskless1 does, but in principle you might want to do this). so far rc.diskless1 only populates, so removing is not a problem. the solution currently in rc.diskless1 actually does a merge of 2-3 different filesystems, so between the mounts you have to populate /conf/etc as well. that's why im using /etc and not /conf/etc, it was becoming to complicated having more than one /etc. the nice thing is that i can use the same root for non diskless too. We have done the same thing here with our large diskless clusters. I really hated not having the same / (root fs) on the server and diskless clients since it made things like updates that much harder. So, we built it such that / is the same on all (and read-only on the diskless crew) We then build a /dev (from mfs with MAKEDEV) and /var (using mtree) and /etc (using the current /etc and /comf/default/etc) (Too bad devfs is not running reliably - the Linux clusters save a some RAM and boot time using that) This whole set up means that if I install a port on the server, all of the clients get it. If I do a make world/etc for the OS, all of the clients get it. (Albeit we have to patch the rc.diskless* again to put back our changes) But it really works very well and saves us lots of grief in configuration and maintainance. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: mtio questions
On Sun, Aug 12, 2001 at 06:03:00PM -0700, Matthew Jacob wrote: I'll answer based upon -stable FreeBSD code. On Sun, 12 Aug 2001, Bernd Walter wrote: Asume the following code examples: int fd; struct mtop mo; char buf[10240]; fd = open(/dev/nsa0, O_RDWR | O_EXLOCK); mo.mt_op = MTREW; mo.mt_count = 0; ioctl(fd, MTIOCTOP, mo); write(fd, buf, 10240); close(fd); Let's not ask whether this is variable record or not. Do you think it's a good idea to always set the blocksize to 10k? Are there better choices than 10k? Are there drives out there that can't work with this? AFAIK it's supposed that drives/drivers have to split the 10k block into smaller physical if the drive is not capable of writing a single 10k block. -- 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
Dell OptiPlex GX100 onboard video
Hi, Yes, I know this has been discussed in the past on this but I couldn't find any solutions so I'd like to actually assist in the solution. Unfortunately at work I was given a Dell OptiPlex GX100 which has an on-board video card that I've yet to see anyone get work under FreeBSD 4.x. I hear -CURRENT has support, but when I ask around, no one can point me to the exact code that supports it so that I may perhaps attempt to backport it to 4.x. Can anyone tell me if it's a myth that the onboard card is not supported in 4.x but is in, what will be, 5.0? If anyone has done any real work with this I'd appreciate being contacted. Also, if I've completly missed a post regarding this issue that solves it, I would appreciate a link :-) Thanks, andrew *-. | Andrew R. Reiter | [EMAIL PROTECTED] | It requires a very unusual mind | to undertake the analysis of the obvious -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fiber NIC support in FreeBSD (specifically the SMC 9432)
Hi! The support for fiber optic was added to -current on 2001/02/07 and MFCed on 2001/06/08 (will be in 4.4 release). So, get new enough system, and go... Bye! On Sun, 12 Aug 2001, D Brearley wrote: I was wondering if there had been any talk of including fiber media support for the tx driver any time soon? I have an SMC 9432FTX NIC and I can only use the 100Base-TX media on it. I would really like to migrate my FreeBSD servers from UTP to fiber. Can we expect to see any further fiber support in freebsd when 5.0 comes out? Thanks! - Don Brearley To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
how to debug a kld module?
Hi, My system panics with a page fault in one of my kernel loadable modules. I want to debug this, but I can't find a way to load that module and its symbol table into gdb. The steps that I have taken are gdb -k /sys/compile/DRAWBRIDGE/kernel.debug vmcore.11 which gives me a normal kenel with debug symbols that I can debug? But, how can I load the offending kld module symbol table as well? Or can I only properly debug this, when I compile the module into the kernel? Thanks, Frank To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: how to debug a kld module?
[EMAIL PROTECTED] (Frank Volf) writes: Hi, My system panics with a page fault in one of my kernel loadable modules. I want to debug this, but I can't find a way to load that module and its symbol table into gdb. The steps that I have taken are gdb -k /sys/compile/DRAWBRIDGE/kernel.debug vmcore.11 which gives me a normal kenel with debug symbols that I can debug? But, how can I load the offending kld module symbol table as well? Or can I only properly debug this, when I compile the module into the kernel? Try following the steps in the developers handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html In particular the section 11.6 Debugging Loadable Modules Using GDB: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x4290.html Rolf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
allocating userland space to call open() on a kernel module
Hello hackers,
I'm currently working on a kld syscall module which needs to read a config
file at startup (MOD_LOAD).
Following the advice of Eugene L. Vorokov, I tried to allocate some userland
space with mmap() to store a open_args struct, fill-it with copyout() /
subyte()... and call open with curproc on first argument.
open() returns 14, EFAULT = Path points outside the process's allocated
space (man 2 open). Allocating userland memory works (mmap() returns 0),
idem for munmap().
I need help.. it would be fine if you can help me. I'm new on modules
coding...
Here's the (bad) code, and thanks in advance (forgive-me for my horrible
english :p).
static void *
malloc_space_userland(const int size)
{
struct mmap_args *ma;
int ret=0;
void *addr;
MALLOC(ma,struct mmap_args *,sizeof(struct mmap_args),M_RING1,M_NOWAIT);
ma-addr=0;
ma-len=size;
ma-prot=PROT_READ|PROT_WRITE;
ma-flags=MAP_ANON;
ma-fd=-1;
if (mmap(curproc,ma)!=0) ret=-1;
FREE(ma,M_RING1);
if ((addr=(void *)curproc-p_retval[0])==MAP_FAILED)
ret=-1;
return (!ret)?addr:NULL;
}
static int
free_space_userland(void *addr,const int size)
{
struct munmap_args *mua;
int ret=0;
MALLOC(mua,struct munmap_args *,sizeof(struct
munmap_args),M_RING1,M_NOWAIT);
mua-addr=addr;
mua-len=size;
if (munmap(curproc,mua)!=0) ret=-1;
FREE(mua,M_RING1);
return ret;
}
static int
read_config(void)
{
struct open_args *oa=NULL;
int filedes=0;
char *fn=CFG_FILENAME; /* #define CFG_FILENAME /etc/foo.bar */
if (!(oa=malloc_space_userland(sizeof(struct open_args {
printf(Unable to allocate space\n); return 0;
} /* WORKS */
copyout(fn,oa-path,strlen(CFG_FILENAME)); /* returns 0. */
susword(oa-flags,O_RDONLY); /* returns 0 */
/* here's the problem, open() returns 14 (EFAULT) ... */
if (!open(curproc,oa) (filedes=(int)curproc-p_retval[0])0) {
/* ... */
}
if (free_space_userland(oa,sizeof(struct open_args))==-1) {
printf(Unable to free space\n); return 0;
} /* WORKS */
return (filedes=0)?0:1;
}
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
pthreads and poll()
Yesterday marked my first attempt at mixing poll() with pthreads.
Needless to say, things did not work out the way I wanted them to. So, I
began the task of finding out the behaviors of various OSes to see if my
code would run fine on them. For your reference and amusement, my results
and test code is included below.
I think that waking only one thread up is the correct behavior, or is there
something that toggles which behavior I want? Perhaps someone with access
to the POSIX standard would care to confirm what the Right Thing is?
Perhaps that someone would then proceed to fix all the incorrect
implementations... or am I asking too much? :)
Looks like I'm going to have to swear off mixing poll() with pthreads for
at least two years if I want my code to be portable...
Aside: I thought that linuxthreads == Linux's implementation of pthreads?
Now why do they behave differently?
-Jon
FreeBSD4/5 OpenBSD Linux IRIX AIX Solaris8
sys lth 2.82.4.1 6.5 4.35.8
poll/tcpaccept NYN N Y N Y
poll/udp NYN Y * N Y
poll/file NYN Y * N Y
Legend:
FreeBSD tested with system pthread (sys), linuxthreads (lth) and GNU pth (pth).
poll/tcpaccept - poll() before accept() of a tcp socket
poll/udp- poll() before recv() of a udp socket
poll/file - poll() before read() of a named fifo socket
Y: only 1 thread wakes up.
N: all threads wake up.
*: IRIX's behavior seems to be nondeterministic. Perhaps IRIX has some AI
to detect the best behavior... Nah...
#include unistd.h
#include stdio.h
#include stdlib.h
#include strings.h
#include assert.h
#include sys/types.h
#include sys/socket.h
#include poll.h
#include fcntl.h
#include netinet/in.h
#include errno.h
#ifdef _THREAD_SAFE
# include pthread.h
#endif
struct pollfd pfd;
void* testcode(void* arg) {
int ret;
struct sockaddr_in addr;
int len;
char buf[1024];
fprintf(stderr,thread %d: polling...\n, (int)arg);
ret = poll(pfd, 1, -1);
if (ret != 1)
fprintf(stderr,thread %d: bad poll return %d\n, (int)arg, ret);
fprintf(stderr,thread %d: reading...\n, (int)arg);
#if defined(TEST_TCP)
len = sizeof(struct sockaddr_in);
ret = accept(pfd.fd, (struct sockaddr*)addr, len);
#elif defined(TEST_UDP)
ret = recv(pfd.fd, buf, 1024, 0);
#elif defined(TEST_READ)
ret = read(pfd.fd, buf, 1024);
#endif
if (ret = 0)
fprintf(stderr,thread %d: broken return %d %d %s\n, (int)arg, ret,
errno, strerror(errno));
fprintf(stderr,thread %d: exit\n, (int)arg);
return 0;
}
int main(int argc, char* argv[]) {
int tmp;
#ifdef _THREAD_SAFE
pthread_t threads[3];
#endif
struct sockaddr_in addr;
int len;
srandom(time(NULL));
bzero(addr, sizeof(struct sockaddr_in));
addr.sin_family=AF_INET;
len=sizeof(struct sockaddr_in);
addr.sin_port=htons(random()%1+1024);
pfd.events = POLLIN;
#if defined(TEST_TCP)
pfd.fd = socket(PF_INET, SOCK_STREAM, 0);
bind(pfd.fd, (struct sockaddr*)addr, len);
listen(pfd.fd, 1);
fprintf(stderr,TCP listening on port %d\n, ntohs(addr.sin_port));
#elif defined(TEST_UDP)
pfd.fd = socket(PF_INET, SOCK_DGRAM, 0);
bind(pfd.fd, (struct sockaddr*)addr, len);
fprintf(stderr,UDP listening on port %d\n, ntohs(addr.sin_port));
#elif defined(TEST_READ)
pfd.fd = open(/tmp/testfile, O_RDONLY);
fprintf(stderr,File polling on /tmp/testfile\n, 94);
#else
assert(0);
#endif
tmp = fcntl(pfd.fd, F_SETFL, O_NONBLOCK);
if (tmp != 0)
fprintf(stderr, fcntl returns %d %d %s\n, tmp, errno, strerror(errno));
#ifdef _THREAD_SAFE
for (tmp = 0; tmp 2; tmp++) {
pthread_create((threads[tmp]), NULL, testcode, (void*)tmp);
}
#endif
testcode((void*)-1);
#ifdef _THREAD_SAFE
for (tmp = 0; tmp 2; tmp++) {
pthread_join(threads[tmp], NULL);
}
#endif
exit(0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Signal Handling
In a program that I am working on, I've decided to catch signal 15, which then calls execl() in the handler to reload the program from the on-disk binary. I am able to send it the signal, it reloads, and works fine. However I could not send the signal again and have the program respond. I then learned, with some help, that the signal needs to be unblocked after each call. It now works as intended. However in reading about this, in Steven's Advanced Programming in the UNIX Environment, he states: Naturally a signal that is being caught by a process that calls exec cannot be caught in the new program, since the address of the signal-catching function in the caller probably has no meaning in the new program file that is execed. Page. 273) This makes sense to me, however doesn't seem to be the case. Three questions: 1) Why, in the first place, does a signal become blocked after it is recieved? Why does the kernel want to do this? 2) If a 10k binary is running, the signal is sent, and the program is reloaded from disk, but is 100k (or 1k even) how does the signal handling function get called, taking into account what Stevens says. Steven states that the sigmask remains for calls across exec, so wouldn't the wrong address to the handler function be used? 3) Is my using of exec, in fact, the best way to reload the program on the fly, from within itself? What would be the best, robust, way to do this in the future? Thank you all for your time, Hans [EMAIL PROTECTED] __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Writing a packet alias translator, need help
I'm trying to write a packet alias translator for a protocol that uses TCP
to setup a UDP streaming session (much like the smedia driver that's
already there). I'm having a problem getting the translated port to mesh
with the actual port. Here's what I've done:
/* msg is a TCP setup packet
struct msg {
u_int32_t ipAddr;
u_int32_t portNumber;
};
*/
null_addr.s_addr = 0;
msg-ipAddr = (u_int32_t)GetAliasAddress(link).s_addr;
my_link = FindUdpTcpOut(pip-ip_src, null_addr,
msg-portNumber, 0, IPPROTO_UDP, 1);
msg-portNumber = (u_int32_t)GetAliasPort(my_link);
What happens is that the IP address gets handled correctly, but not the
port number. The translation occurs in the packet, but it doesn't get
translated to the correct number. For example, the actual port being used
is UDP 16704, but the translation puts 50535 in the packet.
I guess my question is how can I put the correct port number in the TCP
setup packet? How can I then use this port number in the upcoming UDP
stream?
I've never written a NAT translator before, so I'm not sure if
FindUdpTcpOut() does what I think. any help would be appreciated.
Joe Clarke
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: pthreads and poll()
Jonathan Chen wrote: Yesterday marked my first attempt at mixing poll() with pthreads. Needless to say, things did not work out the way I wanted them to. So, I began the task of finding out the behaviors of various OSes to see if my code would run fine on them. For your reference and amusement, my results and test code is included below. I think that waking only one thread up is the correct behavior, or is there something that toggles which behavior I want? Perhaps someone with access to the POSIX standard would care to confirm what the Right Thing is? Perhaps that someone would then proceed to fix all the incorrect implementations... or am I asking too much? :) Looks like I'm going to have to swear off mixing poll() with pthreads for at least two years if I want my code to be portable... We don't provide locking for fd's any longer (I thought this was only in -current, but your results seem to indicate otherwise). If we did, only one thread would wake up. The mistake in your sample seems to be that you're having all threads block on the same fd. Why? We took the approach in -current that it is up to the application to provide locking for fd's. Our libc_r also wraps poll() into non-blocking calls which allows the other threads to run and block on the same fd. When we get blocking down in the kernel (KSEs or a linuxthreads like approach), I'm not exactly sure what would happen. From your results (linuxthreads under FreeBSD), it looks like it should behave as you expect. Aside: I thought that linuxthreads == Linux's implementation of pthreads? Now why do they behave differently? It depends on how things get woken up in the kernel. I don't think I would rely on any particular behaviour... -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Reading files within the kernel (was Re: allocating userland space...)
In message 003101c12411$294adaa0$[EMAIL PROTECTED], Sansonetti Laurent w
rites:
Hello hackers,
I'm currently working on a kld syscall module which needs to read a config
file at startup (MOD_LOAD).
Following the advice of Eugene L. Vorokov, I tried to allocate some userland
space with mmap() to store a open_args struct, fill-it with copyout() /
subyte()... and call open with curproc on first argument.
I really don't understand why people try these obscure mechanisms
to read files within the kernel. There are existing kernel interfaces
for accessing files that are much cleaner than these hacks. You
can't use the familiour open/read/close calls, but using the vnode
interface is really not that hard.
Below is a simple KLD that prints /etc/motd on the console. There's
not a lot involved really, since vn_open(), vn_rdwr() and vn_close()
do most of the hard bits. The most strange stuff is probably the
setting up of the nameidata structure, but even it isn't too
complicated.
To try it, just save the two files below in a directory, and run
make depend
make
kldload ./kernio.ko
(WARNING: not highly tested, so it may crash your machine!)
For further reference, most of the VOP_* functions are documented
in section 9 man pages.
Ian
Makefile --
KLDMOD= true
KMOD= kernio
SRCS= vnode_if.h kernio.c
NOMAN=
CFLAGS+= -I${.CURDIR}/.. -I/usr/src/sys
.include bsd.kmod.mk
- kernio.c --
#include sys/param.h
#include sys/systm.h
#include sys/fcntl.h
#include sys/namei.h
#include sys/vnode.h
#include sys/proc.h
#include sys/malloc.h
#include sys/kernel.h
static int kernio_example(void);
static int kernio_open(int pathseg, const char *path, int flags,
struct proc *p, struct vnode **vpp);
static void kernio_close(struct vnode *vp, int flags, struct proc *p);
static int
kernio_modevent(module_t mod, int type, void *unused) {
switch (type) {
case MOD_LOAD:
return kernio_example();
case MOD_UNLOAD:
break;
default:
break;
}
return 0;
}
static int
kernio_example(void) {
struct vattr vattr;
struct proc *p;
struct vnode *vp;
char *buf, *cp;
int error, filesize, flags, pos, resid;
p = curproc;
flags = FREAD;
buf = NULL;
/* Open the file, and get its size. */
error = kernio_open(UIO_SYSSPACE, /etc/motd, flags, p, vp);
if (error)
return (error);
error = VOP_GETATTR(vp, vattr, p-p_ucred, p);
if (error)
goto errout;
filesize = vattr.va_size;
printf(file size = %d\n, filesize);
/* Allocate space for the file contents. */
MALLOC(buf, char *, filesize, M_TEMP, M_WAITOK);
if (buf == NULL)
goto errout;
/* Read in the complete file to `buf'. */
error = vn_rdwr(UIO_READ, vp, buf, filesize, 0, UIO_SYSSPACE,
IO_NODELOCKED, p-p_ucred, resid, p);
if (error)
goto errout;
/* Silly example; print out the file line by line. */
cp = buf;
for (pos = 0; pos filesize; pos++) {
if (buf[pos] != '\n')
continue;
buf[pos] = '\0';
printf(%s\n, cp);
cp = buf[pos] + 1;
}
errout:
if (buf != NULL)
FREE(buf, M_TEMP);
kernio_close(vp, flags, p);
return (error);
}
static int
kernio_open(int pathseg, const char *path, int flags, struct proc *p,
struct vnode **vpp)
{
struct nameidata nd;
struct vnode *vp;
int error;
NDINIT(nd, LOOKUP, FOLLOW, pathseg, path, p);
#if __FreeBSD_version 50
error = vn_open(nd, flags, 0);
#else
error = vn_open(nd, flags, 0);
#endif
if (error)
return (error);
NDFREE(nd, NDF_ONLY_PNBUF);
vp = nd.ni_vp;
if (vp-v_type != VREG) {
VOP_UNLOCK(vp, 0, p);
vn_close(vp, flags, p-p_ucred, p);
return (EACCES);
}
*vpp = vp;
return (0);
}
static void
kernio_close(struct vnode *vp, int flags, struct proc *p)
{
VOP_UNLOCK(vp, 0, p);
vn_close(vp, flags, p-p_ucred, p);
}
moduledata_t kernio_mod = {
kernio,
kernio_modevent,
0
};
DECLARE_MODULE(kernio, kernio_mod, SI_SUB_DRIVERS, SI_ORDER_ANY);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: zoom modem
On Sun, Aug 12, 2001 at 02:13:55PM -0700, Dan Cox wrote: I am trying to get my internal pci zoom fax modem installed on freebsd. This modem is not a winmodem. My problem is that the only instructions I have are either for windows or Linux. I will include the linux instructions below. Assuming this is acts like other real PCI modems, you need to do the following: 1) Determine the PCI ID of the modem. You can do this pciconf -l, just find the unidentified device that is your modem and look from the chip=0x entry. 2) Add and an appropriate entry to the pci_ids array in /usr/src/sys/isa/sio.c. The ID is the number in hex, the string is a description and the last entry is pretty much magic. ;-) From what I see there, I'd try 0x10 and then 0x14 since 0x10 is slightly more common. 3) Build a new kernel and reboot. 4) If it works, create a diff of the changes you made and submit a PR so other people won't have to mess with this. -- Brooks -- 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: how to debug a kld module?
Rolf Neugebauer wrote: My system panics with a page fault in one of my kernel loadable modules. I want to debug this, but I can't find a way to load that module and its symbol table into gdb. The steps that I have taken are gdb -k /sys/compile/DRAWBRIDGE/kernel.debug vmcore.11 which gives me a normal kenel with debug symbols that I can debug? But, how can I load the offending kld module symbol table as well? Or can I only properly debug this, when I compile the module into the kernel? Try following the steps in the developers handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html In particular the section 11.6 Debugging Loadable Modules Using GDB: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x4290.html Thanks, this is very usefull information, so I feel rather stupid to ask the next question. How exactly do I walk the linker_files structure as described in the developers handbook: gdb -k /sys/compile/DRAWBRIDGE/kernel.debug vmcore.13 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... IdlePTD 3633152 initial pcb at 2e6600 panicstr: page fault (kgdb) print linker_files $1 = -1067722752 (kgdb) print *linker_files $2 = 5 (kgdb) print linker_files-tqh_first Attempt to extract a component of a value that is not a structure pointer. (kgdb) whatis linker_files type = data variable, no debug info What am I doing wrong? Frank To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.2 SMP driver for DiskonChip
Hi, I'm trying to use the M-Systems', DiskonChip on a Dual PIII SBC running the SMP FreeBSD4.2 kernel. However, I get kernel crashes when trying to write to the DiskonChip (on a 4.2FreeBSD SMP kernel on a regular IDE disk) or sometimes even when I try to reboot from an existing FreeBSD 4.2-SMP system already on the DOC. It seems lik the DOC driver is not 4.2FreeBSD-SMP compliant. Has anyone faced this problem already? I will contact the developer of the driver and also M-Sys about this but please let me know how you address this problem. Thanks a lot. Regards, -Srinivas _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Fwd: error in ip_checkinterface code?
I sent the following to net a while back and got a whole one responce. Anyone else have any thoughts? Unless someone has a good reason not to, I'd like to commit the attached patch. -- Brooks - Forwarded message from Brooks Davis [EMAIL PROTECTED] - From: Brooks Davis [EMAIL PROTECTED] Date: Mon, 23 Jul 2001 18:44:18 -0700 To: [EMAIL PROTECTED] Subject: error in ip_checkinterface code? I just ran into what appears to be a bug in the ip_checkinterface code. The problem is that is assumes m-m_pkthdr.rcvif is non-NULL. Apparently this is normally true, but I have some netgraph code that processes it's processes in such a way that they lose their interface pointer which means that when I stick them back into the ip_stack get a panic. A quick patch that fixes the problem is included below. Is this fix correct? -- Brooks Index: ip_input.c === RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.174 diff -u -r1.174 ip_input.c --- ip_input.c 2001/06/23 17:17:58 1.174 +++ ip_input.c 2001/07/24 01:46:22 @@ -559,6 +559,7 @@ * the packets are received. */ checkif = ip_checkinterface (ipforwarding == 0) + m-m_pkthdr.rcvif != NULL ((m-m_pkthdr.rcvif-if_flags IFF_LOOPBACK) == 0) (ip_fw_fwd_addr == NULL); -- 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 - End forwarded message - -- 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
more Newbus questions
First, I would like to thank all of you who answered my first question. I have spent the past couple of days reading through the newbus code, and have a couple more questions. I think I have a pretty good Idea about the device tree by now, but I am a bit confused, as to how the interrupts are handled. Can someone pease explain how the data structure(s) are organized, and used? As far as I can tell, there are several arrays, which are somehow used together, those being intr_handler[], intr_mptr[], intr_mask[], intr_unit[], and intr_countp[]. I find it very difficult to tell by the source code, how these structures are initialized, and how they are used later on. Lastly, there are two arrays, fastintr[] and slowintr[], which also look like some sort of table iwth interrupt handing routine pointers. What are those for, and where is the difference between the two? I admit, I am a bit confused, so I would greatly appreaciate, if someone can clear the whole Newbus IRQ handling stuff for me.. Thanks, JAn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Reading files within the kernel (was Re: allocating userland space...)
Hello Ian, Thanks you for your help, now I can read my cfg file from my module in a easier way ;) A another stupid question, how can I do to stop the loading process in MOD_LOAD event handler (in my case, if the cfg file doesn't exist, it should be better to interrupt..) ? Returning EINTR does not appear to be the good solution ;) Thanks you (again) in advance. -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Very odd tty hanging problem.
I have stumbled across a bug that's driving me bonkers. Here's the setup: - Log in to a 4.2-RELEASE box. - Run mutt (1.2.5i, built from ports) - Get dropped into an editor (new message, reply, it doesn't matter) - Enter insert mode in vi - Paste in 1k (approximately) of text Bam, frozen window. It won't respond to anything. Here's output of top for that string of processes: PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 75136 bicknell 18 0 1348K 924K pause 1 0:00 0.00% 0.00% tcsh 84462 bicknell 10 0 2736K 1904K wait 0 0:00 0.00% 0.00% mutt 84475 bicknell 10 0 620K 232K wait 1 0:00 0.00% 0.00% sh 84476 bicknell 4 0 1900K 1664K ttywri 0 0:00 0.00% 0.00% vi (tcsh - mutt - sh -c vi - vi) Vi always ends up stuck in ttywrite, and yes, I can easily reproduce this over and over. From another window, try to kill the processes as a user, no effect with -9 or regular. Try to kill them as root, no effect normal. Kill them -9 as root, and all but the first shell will go away, here's ps output from an earlier occurance: PID TT STAT TIME COMMAND 20986 p0- IEs+ 0:00.08 -tcsh (tcsh) And top of the same: PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 20986 bicknell 4 0 1344K 908K ttywai 1 0:00 0.00% 0.00% tcsh If I run vi on its own (or cat -, or emacs, etc) I can't make this happen. I can't make it happen with another editor under mutt (eg emacs). But let mutt start vi and paste a reasonable size junk and bam, its frozen. I've also tried it from different terminal emulators, over both ssh and telnet, same results. I'm at a loss as to what might be happening, or what to do next to debug this particular problem. Anyone have a suggestion? -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: the =+ operator
On Fri, 10 Aug 2001, Jan Knepper wrote: I just checked on this =+ and =- with the guy that wrote the first native C++ compiler and he does not recall it at first being that way... of course not. It had changed long before C++. You have to go back to 1976 to find this. I have been programming C++ myself for over 10 years and *never* heard this before. I do not know where it comes from. Guess I'll repeat it. Go find the original V6 Unix Documents for use with the Unix time sharing system and look in there. These were made available ca. 1976. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Large /dev/md0 ramdisk
Hello, I have a need for a rather large ramdisk. From what I've read, md is a better way of going than mfs. I don't want this to be able to swap out. So far I'm having trouble getting md to store anything larger than ~90meg .. OS: FBSD 4.3-S relevant kernel config: options MD_NSECT=80 Then I do a: disklabel -r -w md0 auto newfs /dev/md0c mount /dev/md0c /mnt Then.. while trying to copy over a large file.. it stops.. locks up the term.. (but not the entire system) .. I can't kill the cp proc, end up having to reboot to clear it. df Filesystem1K-blocks UsedAvail Capacity Mounted on /dev/twed0s1a 2032623 287113 158290115%/ /dev/twed1s1e 2032623 488229 138178526%/news /dev/twed0s1e 544066012 171091592 32944914034%/news/spool/news/bin01 /dev/twed1s1f 544066012 172257468 32828326434%/news/spool/news/bin02 procfs440 100%/proc /dev/md0c38760790265 26633425%/mnt It always gets to the exact same number of blocks... 90265 .. anyone have an idea? Please resond offllist since I'm not on hackers.. or you can answer this in fbsd-questions ;) Thanks, Jason --- Robert J. Adams [EMAIL PROTECTED] http://www.siscom.net Looking to outsource news? http://www.newshosting.com SISCOM Network Administration - President, SISCOM Inc. Phone: 937-222-8150 FAX: 937-222-8153 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: the =+ operator
On Mon, Aug 13, 2001 at 07:38:27PM -0600, Ronald G Minnich wrote: On Fri, 10 Aug 2001, Jan Knepper wrote: I just checked on this =+ and =- with the guy that wrote the first native C++ compiler and he does not recall it at first being that way... of course not. It had changed long before C++. You have to go back to 1976 to find this. I have been programming C++ myself for over 10 years and *never* heard this before. I do not know where it comes from. Guess I'll repeat it. Go find the original V6 Unix Documents for use with the Unix time sharing system and look in there. These were made available ca. 1976. Like this? :) http://cm.bell-labs.com/cm/cs/who/dmr/cman.ps Look at page 8 of that file... it indeed shows the lvalue =op expression syntax Alson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Large /dev/md0 ramdisk
Robert, Please forgive me not answering your question, but just responding to an issue you've raised. From what I've read, md is a better way of going than mfs. I have seen several references to md being preferred to mfs but have been unable to find any detailed comparison or evaluation. To what reference were you referring? I've also seen it suggested that mfs is to go away, leaving only md. For happy mfs users like myself who enjoy the convenience of a simple flexible fstab entry sufficing for memory backed non-persistent filesystems, that is of some concern. Perhaps someone on -hackers could provide a good pointer or give details. -Andrew- -- __ | -Andrew J. Caines- Unix Systems Engineer [EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
Well, it's now been about 2 months since the initial NetBSD import discussion occured on this list, and as far as I can tell, here's where we stand. - David O'Brien did a vendor import of the unported NetBSD rc system - there was a group consensus that we needed to come up with some intelligent talking points before we approached the NetBSD maintainer about how to do this, how coordinated we want the two rc systems to be, and what not. I'm back in town for a few weeks and I'd like to get this project done, especially having noted that it's really a sweet system. Is there anything we need to talk about still, or do we just need an unemployed guy who understands the problem to bang out a big pile of code. If we need to hold joint discussions, what are the outstanding issues? If not, then I'm your unemployed guy with time to kill. -Kevin Way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
On Tue, 14 Aug 2001, Kevin Way wrote: Well, it's now been about 2 months since the initial NetBSD import discussion occured on this list, and as far as I can tell, here's where we stand. - David O'Brien did a vendor import of the unported NetBSD rc system - there was a group consensus that we needed to come up with some intelligent talking points before we approached the NetBSD maintainer about how to do this, how coordinated we want the two rc systems to be, and what not. I'm back in town for a few weeks and I'd like to get this project done, especially having noted that it's really a sweet system. Is there anything we need to talk about still, or do we just need an unemployed guy who understands the problem to bang out a big pile of code. If we need to hold joint discussions, what are the outstanding issues? If not, then I'm your unemployed guy with time to kill. -Kevin Way Well, I promised to be in on this. I had some nice changes that I made but decided that I should hold off (and then I subsequently lost them, long story). I've switched jobs and only now have had time to resurface. I'm very interested in this as well. I'll be installing a current box and will be tweaking the rc.d system. Although, I don't have the unemployed status, I'm still interested in the development of this. Here's my big question. Do we try to maintain our boot order? Or are we going to go with the boot order as presented by the NetBSD stuff? -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
