Re: Kernel Hacking (i tried not to make it lame)
* [EMAIL PROTECTED] [EMAIL PROTECTED] [010125 19:04] wrote: hey guys i know you probably get this question all the time but i am looking into getting into doing somekernel hacking first i will tell you some thing i have assumed about it: 1.) you should know atleast more programming language well (probably C would be best) C is necessary including a strong understanding of the pre-precessor, knowing a bit about 'make' is also pretty important. 2.) you should know some basic stuff about FreeBSD internels (i am planning on getting The Design and Implementation of the 4.4BSD Operating System Well more than 'basic' hopefully. :) Good choice on a book, others to look at are: "UNIX Internals 'the new frontiers'" Vahalia "The Basic Kernel Source Secrets" Jolitz and of course "The UNIX Hater's Handbook" that is about it the rest really is a blur and is so complex and huge i have no idea where to begin hope i wasn't to lame guys :-) Find a local user group, find and talk to some kernel hackers, but step away at the first sign of dizzyness or lightheadness. Feel free to ask on the mailing lists if something is confounding you, just be sure to check the mailing list archives first. best of luck, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel Hacking (i tried not to make it lame)
On Fri, 26 Jan 2001, you wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] [010125 19:04] wrote: hey guys i know you probably get this question all the time but i am looking into getting into doing somekernel hacking first i will tell you some thing i have assumed about it: 1.) you should know atleast more programming language well (probably C would be best) C is necessary including a strong understanding of the pre-precessor, knowing a bit about 'make' is also pretty important. 2.) you should know some basic stuff about FreeBSD internels (i am planning on getting The Design and Implementation of the 4.4BSD Operating System Well more than 'basic' hopefully. :) Good choice on a book, others to look at are: "UNIX Internals 'the new frontiers'" Vahalia "The Basic Kernel Source Secrets" Jolitz and of course "The UNIX Hater's Handbook" that is about it the rest really is a blur and is so complex and huge i have no idea where to begin hope i wasn't to lame guys :-) Find a local user group, find and talk to some kernel hackers, but step away at the first sign of dizzyness or lightheadness. Feel free to ask on the mailing lists if something is confounding you, just be sure to check the mailing list archives first. best of luck, The manual pages are very helpfull although not the complete references, the sources itself is the saviour. I remembered porting back cd9660 to 2.2.x tree, and now look forward porting softupdates (If anybody can give me some light I really appreciate that). I'm reviewing sources from current, stable and from other BSD project such OpenBSD to pick all the good stuffs. I'm a happy 2.2.x user. -- /\_ / ./__ / __/ I do understand.. / ___/ / / ^^ *warf* *warf* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Linux emulation / arla 0.34.6
On Wed, Jan 24, 2001 at 10:15:53PM -0600, Chris Csanady wrote: On Wed, Jan 24, 2001 at 12:50:29PM -0600, Chris wrote: Silly me--I forgot to mention, this is with FreeBSD 4.2-STABLE. How recent -stable? A bug like this was fixed recently. If it's older than a week, Try upgrading :-) Kris Hmm, are you referring to this commit? It appears to been MFC'd on 11/07, so I hope not. :) I will rebuild and find out though.. That could be the one I'm thinking of. Kris -- NOTE: To fetch an updated copy of my GPG key which has not expired, finger [EMAIL PROTECTED] PGP signature
Re: Kernel memory allocation bug ...
Alfred Perlstein wrote: * Xavier Galleri [EMAIL PROTECTED] [010125 10:36] wrote: Alfred Perlstein wrote: I told you about 3 times to provide us with a stipped down source code module which reproduces this "bug". You haven't done this. Therefore I can't help you. I did not expect to make trouble to anyone, just sorry for the inconvenience ... I am not sure that we could easily provide for some code sample on this issue since this could be expensive, but I will see for sure (I easily understand that this is easier for anybody to track down a problem in such conditions ;-). That said, I still remain astonished not to get any comments or questions or hints or any other reactions about the analysis I have already provided. I have seen other mails in this list that exposed different kind of issues without requiring code sample to feed a constructive discussion. Did I miss something ? You missed the two other people reporting "bugs" the same week you began to. I spend a couple of hours trying to track them down and they wound up being errors in thier code and not FreeBSD's. Honestly the symptoms you describe lean towards error on your part. Even if they are not your error they seem pretty hard to reproduce. You've been complaining about this problem for at least a week. Producing some code so that we can test couldn't take more than a couple of hours and would have probably had your issue resolved by now. This is why I'm irritated that you still haven't provided any code to reproduce it. I wish I could avoid this misunderstanding ! The fact is that I was expecting some hints to track down the problem on myown, especially concerning the FreeBSD behaviour in case of free list shortage. Also, I would appreciate to know if my understanding of the figures I got from 'cnt' or of the scheduling behaviour with regard to kernel preemption is correct. I think this would be helpful for me to build the code sample you are requesting. I do appreciate your mini-kernel debug howto, I've got it saved for future reference. I am sincerely happy that I could provide something helpful ... Well, actually, it sounds that I did go to far to be able to retract myself, so I will let you know of any progress I will make asap ;-) Cheers, Xavier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Kernel Hacking (i tried not to make it lame)
Dear Ariff, I remembered porting back cd9660 to 2.2.x tree, and now look forward porting softupdates (If anybody can give me some light I really appreciate that). I'm reviewing sources from current, stable and from other BSD project such OpenBSD to pick all the good stuffs. I'm a happy 2.2.x user. I think Yahoo! is using still on 2.2.8. There are some people on this list who work for Yahoo!, so you could try to drop them a line. I can imagine that they are interested in softupdates. Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver info (which card then?)
On Fri, 26 Jan 2001, Greg Lehey wrote: Performance isn't even the main thing. As I said earlier, it's plain bloody unreliable. Linux people avoid the EtherExpress because they think something is wrong with the card. They were surprised when I reported that it works without any problems under FreeBSD. Do we really want to change that? Slightly off subject but with all the discussion about not Intel playing nicely with the FreeBSD developers... I've always had the best reliability, performance, and lower CPU usage with the Intel EtherExpress Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there better cards out there that I should be looking at? --- Mike Wade ([EMAIL PROTECTED]) Chief Technical Officer CDC Internet, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver info (which card then?)
Linux people avoid the EtherExpress because they think something is wrong with the card. Intel EtherExpress Pro 10/100B cards in FreeBSD These cards work well in our many 3.x and 4.x systems. But I just built up a Redhat 6.2 box with one, and all seemed to be working fine, but after a while I started having various problems starting net services. The box would boot, but often would "hang" indefinitely when "Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro NIC, new MB, different RAM, other cables, everything, but no change. After I switched to a linksys NIC, voila- everything worked without a problem. (so far) Of course the Intel NICs still work perfectly when put into a spare BSD system. So it's *not* that the cards themselves are unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC conflict of some sort? -=Jim=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Divert Sockets Fragmentation revisited
Having run lsof I can verify that the program IS reading on that port
number.
Has anyone else on the hacker list had problems with diverting
fragmented datagrams??
Alwyn Goodloe
[EMAIL PROTECTED]
On Fri, 26 Jan 2001, Patrick Bihan-Faou wrote:
Hi,
Sorry to state something that is obvious, but when you bind your socket to
the port, you have the port in the correct (network) order ?
i.e. do you use htons(DIVERTPort) ?
If you have lsof installed, run it and look at the port number that your
program listens on.
Patrick.
Here is the important code fragments:
Note: I have played with the MAX_PACKET_SIZE in hopes that it would make
some
difference but to no avail.
#define MAX_PACKET_SIZE 30
#define DIVERTPort 4422
#define ACTIVE_UDP_PORT 3322
if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) 0)
sys_error("divert socket error");
set_sock_data(server_divert,PF_INET,DIVERTPort,INADDR_ANY);
printf("Step 1 \n");/* Register address and port with the system */
if (bind(divert_sock, (struct sockaddr*)
server_divert,sizeof(server_divert)) 0)
sys_error("server_divert bind error");
for ( ; ; ) {
n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0,
( struct sockaddr * ) client_add,clilen);
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
gpc Pascal Compiler from FreeBSD
Title: gpc Pascal Compiler from FreeBSD Is anyone using this? I can seem to get the compiler to find any of the units. I have set the GPC_INCLUDE_DIR to where the units are but still no luck. Roderick P. Person Programmer II [EMAIL PROTECTED] I'm not indecisive. Am I indecisive? - Jim Scheibel, mayor of St. Paul Minnesota
Re: if_fxp driver info (which card then?)
Mike Wade writes: On Fri, 26 Jan 2001, Greg Lehey wrote: Performance isn't even the main thing. As I said earlier, it's plain bloody unreliable. Linux people avoid the EtherExpress because they think something is wrong with the card. They were surprised when I reported that it works without any problems under FreeBSD. Do we really want to change that? Slightly off subject but with all the discussion about not Intel playing nicely with the FreeBSD developers... I've always had the best reliability, performance, and lower CPU usage with the Intel EtherExpress Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there better cards out there that I should be looking at? 3C905 -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver info (which card then?)
At 08:51 AM 01/26/2001, Mike Wade wrote: On Fri, 26 Jan 2001, Greg Lehey wrote: Performance isn't even the main thing. As I said earlier, it's plain bloody unreliable. Linux people avoid the EtherExpress because they think something is wrong with the card. They were surprised when I reported that it works without any problems under FreeBSD. Do we really want to change that? Slightly off subject but with all the discussion about not Intel playing nicely with the FreeBSD developers... I've always had the best reliability, performance, and lower CPU usage with the Intel EtherExpress Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there better cards out there that I should be looking at? Why dont some people get the point even when you hit them in the head with a hammer? The point is that the driver quality is more important than the "card" To get completely off base, this is which is why we SELL our software. Implementation technique is usually more decisive in determining functionality and performance than the hardware itself. its something that people in the know are willing to pay for (sometimes). Certainly some hardware is better than others, but a bad driver with good hardware is useless. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver info (which card then?)
At 09:47 AM 01/26/2001, Jim Sander wrote: Linux people avoid the EtherExpress because they think something is wrong with the card. Intel EtherExpress Pro 10/100B cards in FreeBSD These cards work well in our many 3.x and 4.x systems. But I just built up a Redhat 6.2 box with one, and all seemed to be working fine, but after a while I started having various problems starting net services. The box would boot, but often would "hang" indefinitely when "Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro NIC, new MB, different RAM, other cables, everything, but no change. the eepro100 driver is badly broken in linux (havent you been paying attention?). it took me a few hours to fix it. They dont reset the card properly on an overrun, which causes it to lock up. Clearly the driver as is is unusable in a heavy use environment. DB After I switched to a linksys NIC, voila- everything worked without a problem. (so far) Of course the Intel NICs still work perfectly when put into a spare BSD system. So it's *not* that the cards themselves are unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC conflict of some sort? -=Jim=- 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: if_fxp driver info (which card then?)
At 11:43 AM 01/26/2001, Aleksandr A.Babaylov wrote: Mike Wade writes: On Fri, 26 Jan 2001, Greg Lehey wrote: Performance isn't even the main thing. As I said earlier, it's plain bloody unreliable. Linux people avoid the EtherExpress because they think something is wrong with the card. They were surprised when I reported that it works without any problems under FreeBSD. Do we really want to change that? Slightly off subject but with all the discussion about not Intel playing nicely with the FreeBSD developers... I've always had the best reliability, performance, and lower CPU usage with the Intel EtherExpress Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there better cards out there that I should be looking at? 3C905 I disagree. The if_fxp driver is far superior to the if_xl driver. In other OS's your mileage may vary. DB -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
I think it is worth doing. A quick google search shows that the linux folks discussed the AIX thingy in March 1999, but I don't think they actually implemented. From the discussion, it appears that the fcntl would be useful and (not having seen your patches), almost certainly trivial to implement. -Matt :Hi, : :I've modified the kerenl to add F_CLOSEM functionality to fcntl. :(I've seen this in some AIX docs). : :The purpose is allow a process to close all its filedescriptors starting :from a given value without issuing thousands of close() syscalls. :This may be used for programs that daemonize themselves (or one of :their children) after some amount of work, when many fd's has been :opened. The program would simply call : fcntl(minclose, F_CLOSEM, 0); : :The patch concerns /sys/kern/kern_descriptors.c and fcntl.h :(and of course the corresponding manpage). : :Is this functionality worth inclusion in the kernel (or should I throw :away the patch)? are there any kind souls to review the patch? : :cheers, :mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel memory allocation bug ...
Xavier Galleri wrote: [...] You've been complaining about this problem for at least a week. Producing some code so that we can test couldn't take more than a couple of hours and would have probably had your issue resolved by now. This is why I'm irritated that you still haven't provided any code to reproduce it. [...] Well, actually, it sounds that I did go to far to be able to retract myself, so I will let you know of any progress I will make asap ;-) Ok, I'm back again ;-) and this time, I got something for you ... Basically, what I did, is to write a little SYSCALL kld module to allow controlling calls to MALLOC/FREE from user space. This way, I can issue some filesystem-intensive command (tar something-bigger-than-memory-size) in order to create the free list shortage. Then, I use my test program to issue several MALLOC in kernel space. What I actually noticed is that, when the free list felt below 120 or alike, I can issue several thousands successful MALLOC as long as the asked size is no more than one or a few pages. But, when I ask for numerous pages (32Kb), then the process is falling asleep (this is analysed with my manual stack analysis process ;-), whilst the M_NOWAIT flag has been set (of course !). Everything is almost entirely self-documented in the attached kmem.tar.gz file. I hope this will help and I am eager to hear from you soon. Have a nice WE, Regards Xavier kmem.tar.gz
Re: Divert Sockets Fragmentation revisited
Alwyn Goodloe writes: Guys still having problems with divert sockets and fragmentation. As I said in a previous post the divert operations and corresponding program work fine when the datagram sent have size MTU (1500) but when the datagram has size MTU and hence get fragmented the recfrom just waits never receiving anything. I am attaching the relevent code fragments below. tcpdump tells me that the packets arrive on the interface. Hence I know the fragments arrive. Now my ipfw commands are: ipfw add 6 divert 4422 udp from any to any 3322 in ipfw add 65000 allow ip from any to any I think the problem is that the first fragment is matching your rule, but not subsequent fragments (because the port number is only contained in the first fragment..) Now I thought that that maybe the divert being so specific was a problem so I tried flushing ipfw and using the command: ipfw add 6 divert 4422 ip from any to any thus diverting any ip packets and still nothing. That doesn't make sense.. Try adding the "log" keyword to your ipfw commands, or checking the stats with "ipfw show" so you can see exactly what's being diverted. Now according to the man page on divert: Incomming packets which get diverted are fully reassembled before delivery of any one fragment. Diversion of any one packet causes the entire packet to get diverted. I different fragments get diverted to different ports, then which port ultimately gets diverted is unpredictable. I was under the impression that the packets wern't reassemblembed before diversion. Am I wrong here? Yes... but all fragments must match. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pthreads and kqueue
On 25 Jan 2001, Kevin Mills wrote: Well, there are wrappers in the libc_r code (libc_r/uthread/uthread_kevent.c) and I seem to recall posts on -stable saying that kqueue could now be used with user threads (around the 4.1.1 time frame, I think). I could be wrong :) This seems like a strange way to implement your solution, though ... from the sounds of it, you can only have one concurrent connection to your authentication server via this library, which sounds extremely lame. Do the clients just sit around forever until the server returns? The serialization this library forces isn't too scalable. The library is reentrant and will allow different threads to call into it (there isn't a mutex serializing the entry point or anything like that). However, the call to the backend is done with a blocking call. The communication with the backend is generally very quick. However, if the backend gets too busy I want to make sure I don't starve the other connections. A thread pool seemed the best way to tackle this. I'd be very open to other suggestions if you have any! Also, your proprietary library has to be threadsafe too. Particularly if it blocks... it'll probably block the whole process instead of the individual thread. Unless we figured out a way to fix that :) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
At 10:33 26/01/01 -0800, Matt Dillon wrote:
I think it is worth doing. A quick google search shows that
the linux folks discussed the AIX thingy in March 1999, but
I don't think they actually implemented. From the discussion,
it appears that the fcntl would be useful and (not having seen
your patches), almost certainly trivial to implement.
you're right. (I can resend it as a tar file...)
*** kern_descrip.c Fri Jan 26 19:42:18 2001
--- kern_descrip.c.new Fri Jan 26 20:24:07 2001
***
*** 364,369
--- 364,387
(caddr_t)(intptr_t)uap-arg, sizeof(fl));
}
return(error);
+
+ /* close all descriptors starting from a given value */
+ case F_CLOSEM:
+ {
+ i = uap-fd;
+
+ p-p_retval[0] = 0;
+ if ((unsigned)i = fdp-fd_nfiles) {
+ return (EBADF);
+ }
+ for (; i=fdp-fd_lastfile; i++) {
+ struct close_args uap; /* XXX. requires _SYS_SYSPROTO_H_ */
+ uap.fd = i;
+ close(p, uap);
+ }
+ return 0;
+ }
+
default:
return (EINVAL);
}
The F_CLOSEM is added to sys/fcntl.h
fcntl.diff
*** fcntl.h Fri Jan 26 20:24:45 2001
--- fcntl.h.new Fri Jan 26 20:25:39 2001
***
*** 156,161
--- 156,162
#define F_GETLK 7 /* get record locking
information */
#define F_SETLK 8 /* set record locking
information */
#define F_SETLKW9 /* F_SETLK; wait if blocked */
+ #define F_CLOSEM 10 /* close open fd's larger = arg
*/
/* file descriptor flags (F_GETFD, F_SETFD) */
#define FD_CLOEXEC 1 /* close-on-exec flag */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
packet redirection design problem [Divert Sockets Fragmentation revisited]
"IP filtering engines" that do something to packet based on rule matching have a problem when fragmentation comes to play. In the case of a "packet redirector' such as divert, the problem is that only the first fragment will match the rule, if the rule uses ports or whatever info contained in the payload. The problem occurs if the packet (that should match) is subject to change by the engine (either redirection, nat, blocking, ...) IP Filter handles such situation with specific code. It would be a nice thing if this is added to standard code so that packet filters writers do not need to add their own. Any opinions? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
: :At 10:33 26/01/01 -0800, Matt Dillon wrote: : I think it is worth doing. A quick google search shows that : the linux folks discussed the AIX thingy in March 1999, but : I don't think they actually implemented. From the discussion, : it appears that the fcntl would be useful and (not having seen : your patches), almost certainly trivial to implement. : : :you're right. (I can resend it as a tar file...) : : :*** kern_descrip.c Fri Jan 26 19:42:18 2001 :--- kern_descrip.c.new Fri Jan 26 20:24:07 2001 :... Yah, something like that. You can test whether the descriptor is valid before calling close() on it, which should make it a lot faster. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Your message has been bounced by another.com
Hello, this is an automated message from another.com. We have tried to send your email to the address below, but we cannot find a user with that address. Please check the address of the person you are emailing and try again. [EMAIL PROTECTED] If you need further help, email us at [EMAIL PROTECTED] and a real, live human being will be happy to assist you. If you want to open your own another.com account then go to http://www.another.com/ Thanks, The another.crew freebsd-hackers-digestFriday, January 26 2001Volume 05 : Number 020 In this issue: SYSINIT for userland? RE: SYSINIT for userland? Re: SYSINIT for userland? RE: SYSINIT for userland? Re: SYSINIT for userland? Re: SYSINIT for userland? NFS server out of mbuf's? Re: if_fxp driver info resource overheads 3ware ATA RAID 3DM management utility available Kernel Hacking (i tried not to make it lame) Re: if_fxp driver info Divert Sockets Fragmentation revisited Re: Kernel Hacking (i tried not to make it lame) Re: Kernel Hacking (i tried not to make it lame) Re: Divert Sockets Fragmentation revisited Re: Kernel Hacking (i tried not to make it lame) Re: Kernel Hacking (i tried not to make it lame) Re: FreeBSD Linux emulation / arla 0.34.6 Re: Kernel memory allocation bug ... RE: Kernel Hacking (i tried not to make it lame) Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) Re: Divert Sockets Fragmentation revisited Re: Divert Sockets Fragmentation revisited gpc Pascal Compiler from FreeBSD Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) [kernel patch] fcntl(...) to close many descriptors Re: [kernel patch] fcntl(...) to close many descriptors Re: Kernel memory allocation bug ... Re: Divert Sockets Fragmentation revisited Re: pthreads and kqueue Re: NFS server out of mbuf's? Re: [kernel patch] fcntl(...) to close many descriptors packet redirection design problem [Divert Sockets Fragmentation revisited] Re: [kernel patch] fcntl(...) to close many descriptors -- Date: Thu, 25 Jan 2001 11:52:53 -0800 From: Alfred Perlstein [EMAIL PROTECTED] Subject: SYSINIT for userland? Has anyone done any work for FreeBSD or GNU C that allows for SYSINITs in userland, meaning just having to specify a function and arg to be called at a certain time during program startup? I know you can do some evil magic with overloading special shared object symbols, but it is evil magic. :) Anyone know of another OS that supports this? Any standards for it on the way? - -- - -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Date: Thu, 25 Jan 2001 12:07:54 -0800 (PST) From: John Baldwin [EMAIL PROTECTED] Subject: RE: SYSINIT for userland? On 25-Jan-01 Alfred Perlstein wrote: Has anyone done any work for FreeBSD or GNU C that allows for SYSINITs in userland, meaning just having to specify a function and arg to be called at a certain time during program startup? I know you can do some evil magic with overloading special shared object symbols, but it is evil magic. :) Anyone know of another OS that supports this? Any standards for it on the way? Use C++ with static instances of classes that have constructors. - -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Date: Thu, 25 Jan 2001 12:16:07 -0800 From: Alfred Perlstein [EMAIL PROTECTED] Subject: Re: SYSINIT for userland? * John Baldwin [EMAIL PROTECTED] [010125 12:09] wrote: On 25-Jan-01 Alfred Perlstein wrote: Has anyone done any work for FreeBSD or GNU C that allows for SYSINITs in userland, meaning just having to specify a function and arg to be called at a certain time during program startup? I know you can do some evil magic with overloading special shared object symbols, but it is evil magic. :) Anyone know of another OS that supports this? Any standards for it on the way? Use C++ with static instances of classes that have constructors. I've got a pretty good idea of how it could be done in C++. Have a global list that each object adds itself to in sorted order (via static constructor), the manipulation should be serialized, but this still isn't a solution for C. - -- - -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe
Re: Pthreads with sprintf/dtoa
on Thu, 25 Jan 2001 Mike Smith wrote: __dtoa has static locals. Bad function, no biscuit. I think this can be a serious problem for any threaded application, I have not tested your patch yet, you think this is only a temporary solution right? Have you commited this patch to current? Is somebody else working on that? Thanks and regards, Alex -- Email: Alexander Hausner [EMAIL PROTECTED] NIC-HDL: AH194-RIPE PGP Key ID: 1024/D272F9B5 PGP Key fingerprint: 45 CB 7A 6A 24 81 71 14 CE 11 27 53 36 63 AD 1C PGP Public-Key: https://www.luga.or.at/pgppubkeys/D272F9B5.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
libkvm and DB
Hi there, I'm porting some stuff from FreeBSD 3.3 to 4.2 which uses libkvm. The old one had a DB *db member in struct __kvm (for dbopen(...) calls), but in 4.2 it's missing, so do you have to use slow nlist calls or am I missing something here? Thx in advance Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
specify a different kernel to boot
Is there a way to specify a kernel other than /kernel to boot from? I do not want to do this manually, I want to put it into some configuration file. Thanks, -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
driver for Matrox Meteor II frame grabber
Hello All, I am fairly new to freebsd, but have been asked to develop a driver for the Matrox Meteor II card. (To the best of my knowledge, there is currently no such driver in fbsd, please correct me if I'm wrong..) My first initial thoughts were, 'ok, let's base it as much as possible on the Meteor I driver, naturallymaking changes for hardware differences where applicable. However, I've just read a couple of archive entries about a new method for drivers based on a 'newbus' system. My questions are: (i) where, if at all, can I find info/tutorials/examples on driver-writing with this method? (ii) what are the benefits of the newbus method? (iii) is it still at all acceptable to write drivers using the old style/method? If these issues are better posted to another mailing list, please advise... Thanks very much in advance, Jeff Brooke
Re: PCI changes break HP Docking Station
In message [EMAIL PROTECTED], Brooks Davis さんいわく: I plugged my HP Omnibook 4150 into my dock for the first time in a couple months only to discover that I couldn't attach any of the PCI devices in it. I'm running -current as of sometime in the last week or so. I traced the problem to the new PCI code comitted six weeks ago. Specificaly: Would you send me raw memory block,by executing acpidump -o omnibook.dsdt? Device docking can be handled by ACPI. Takanori Watanabe a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: specify a different kernel to boot
Zhiui Zhang [EMAIL PROTECTED] writes: Is there a way to specify a kernel other than /kernel to boot from? I do not want to do this manually, I want to put it into some configuration file. Thanks, 'man loader' DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthreads with sprintf/dtoa
on Thu, 25 Jan 2001 Mike Smith wrote: __dtoa has static locals. Bad function, no biscuit. I think this can be a serious problem for any threaded application, I have not tested your patch yet, you think this is only a temporary solution right? Have you commited this patch to current? Is somebody else working on that? There are still serious problems; Tor pointed out that the Bigint freelist probably needs protection too. Personally, I think the entire interface is totally bogus, and the allocator should just call malloc. I don't have any benchmarks to test printf speed though... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pthreads with sprintf/dtoa
* Mike Smith [EMAIL PROTECTED] [010126 15:00] wrote: on Thu, 25 Jan 2001 Mike Smith wrote: __dtoa has static locals. Bad function, no biscuit. I think this can be a serious problem for any threaded application, I have not tested your patch yet, you think this is only a temporary solution right? Have you commited this patch to current? Is somebody else working on that? There are still serious problems; Tor pointed out that the Bigint freelist probably needs protection too. Personally, I think the entire interface is totally bogus, and the allocator should just call malloc. I don't have any benchmarks to test printf speed though... This could also be solved by using pthread_getspecific(3) and friends to reduce the amount of malloc calls in persistant threads. Short lived threads might have to deal with some overhead, but long lived ones will be ok. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel Hacking (i tried not to make it lame)
On Fri, Jan 26, 2001 at 01:31:50PM +0100, Koster, K.J. wrote:
I think Yahoo! is using still on 2.2.8. There are some people on this list
who work for Yahoo!, so you could try to drop them a line. I can imagine
that they are interested in softupdates.
I'd imagine that just upgrading machines to recent versions of FreeBSD
would be just as easy as trying to push out that kind of update.
I'd encourage all others who are looking for softupdates in 2.2.8 to
just upgrade to 4.2-{RELEASE,STABLE}.
--
Bill Fumerola / [EMAIL PROTECTED]
ps. not speaking for my employer, etc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver info (which card then?)
On Friday, 26 January 2001 at 9:47:38 -0500, Jim Sander wrote: Linux people avoid the EtherExpress because they think something is wrong with the card. Intel EtherExpress Pro 10/100B cards in FreeBSD These cards work well in our many 3.x and 4.x systems. But I just built up a Redhat 6.2 box with one, and all seemed to be working fine, but after a while I started having various problems starting net services. The box would boot, but often would "hang" indefinitely when "Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro NIC, new MB, different RAM, other cables, everything, but no change. Yes, these are exactly the problems I've heard of. After I switched to a linksys NIC, voila- everything worked without a problem. (so far) Of course the Intel NICs still work perfectly when put into a spare BSD system. So it's *not* that the cards themselves are unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC conflict of some sort? As I mentioned earlier, it's the drivers (two different ones) themselves. Linux people have different opinions about which is worse, but they do agree that both are pretty bad. That's why I've been saying that we shouldn't be looking at porting them. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI changes break HP Docking Station
On Sat, Jan 27, 2001 at 07:21:05AM +0900, Takanori Watanabe wrote: Would you send me raw memory block,by executing acpidump -o omnibook.dsdt? Device docking can be handled by ACPI. It's now online at: http://www.one-eyed-alien.net/~brooks/FreeBSD/dock/omnibook.dsdt I'd be happy to test any docking related ACPI work. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: IDE CDRW
One more similar question: Does/will FreeBSD support ATAPI CD-R(W) drives in disk-at-once mode, perhaps using burncd(1)? I wanted to burn some audio CDs in that manner but burncd on 4-stable didn't support DAO writing. Thank you, Eugene -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kris Kennaway Sent: Wednesday, January 24, 2001 6:53 PM To: Felix-Antoine Paradis Cc: [EMAIL PROTECTED] Subject: Re: IDE CDRW On Wed, Jan 24, 2001 at 05:04:23PM -0500, Felix-Antoine Paradis wrote: Just a simple question, FreeBSD doesn't support/emulate any IDE CDRW? It supports them just fine.. Perhaps your question was really "does FreeBSD emulate a SCSI interface to ATAPI drives?", in which case the answer is "no". They are still fully functional however. Kris -- NOTE: To fetch an updated copy of my GPG key which has not expired, finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE CDRW
On Fri, Jan 26, 2001 at 04:25:15PM -0800, Eugene M. Kim wrote: One more similar question: Does/will FreeBSD support ATAPI CD-R(W) drives in disk-at-once mode, perhaps using burncd(1)? I wanted to burn some audio CDs in that manner but burncd on 4-stable didn't support DAO writing. Don't know; you'd have to do some research yourself into this one, I think. Kris PGP signature
More error message changes? (Re: mkdir diff)
There were a few other places where I noticed (long time ago, but I've now written it all down) somewhat strange messages: mkdir / gives: mkdir: /: Is a directory whereas mkdir /usr gives: mkdir: /usr: File exists Is this a bug in the kernel to return EISDIR in case of "/" or is it a 'feature'? Further, various other programs have a variant of the message weirdness that mkdir had, though this is defensible in some cases as another message is added, e.g. in sh: echo "aa" /tmp/a/b gives: cannot create /tmp/a/b: directory nonexistent. The other cases are present in rm, touch, chmod, cat, ls, cp, mv (possible more...). The messages are all ok if one remembers the exact meaning of the error message as decribed in intro(2) but the short messages that strerror et al produce are misleading when one does not expand further (as opposed to e.g. the sh example) For the following I assume /tmp/e is a file, and /tmp/a does not exist. rm /tmp/e/f gives: rm: /tmp/e/f: Not a directory (better: rm: /tmp/e: Not a directory) touch /tmp/a/b: touch: /tmp/a/b: No such file or directory (better: touch: /tmp/a: No such file or directory, as touch is supposed to create the file if it doesn't exist) touch /tmp/e/f: touch: /tmp/e/f: Not a directory (better: touch: /tmp/e: Not a directory) chmod +x /tmp/e/f: chmod: /tmp/e/f: Not a directory (better: chmod: /tmp/e: Not a directory) cat /tmp/e/f: cat: /tmp/e/f: Not a directory (better: cat: /tmp/e: Not a directory) ls /tmp/e/f: ls: /tmp/e/f: Not a directory (better: ls: /tmp/e: Not a directory) cp /tmp/e/f f: cp: /tmp/e/f: Not a directory (better: cp: /tmp/e: Not a directory) mv /tmp/e/f f mv: rename /tmp/e/f to f: Not a directory if g does not exist: mv /tmp/e/f g/f mv: rename /tmp/e/f to g/f: Not a directory (not sure what do to here, 2 directories, so check/mention both with an expanded message?) Of course, these messages can changed by changing: 1. the messages that go with errno, e.g. "Not a directory" to "Part of the directory name is not a directory" or something 2. check for these cases in the given programs. 3. expand the error message as sh does. I actually like the idea of making the messages that strerror produces more verbose but maybe everyone feels the current messages should stay as they are standard?. Regards, Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NEWBUS: multiple calls needed?
Hi, all!
I am writing a device driver for a device that has three separate
memory areas (plus a 256-byte IO block). At first glance, it
would seem that the correct thing would be something like:
for(x = 0; x 3; x++) {
device-mem[x] = bus_alloc_resource(dev, SYS_RES_MEMORY,
device-rid_mem[x], 0, ~0, 1, RF_ACTIVE);
if(device-mem[x] == NULL)
FAIL;
device-bustag[x] = rman_get_bustag(device-mem[x]);
device-bushandle[x] = rman_get_bushandle(device-mem[x]);
device-virt_addr[x] = rman_get_virtual(device-mem[x]);
}
The memory areas "appear" to be fixed relative to each other:
mem1 == base + 0x00 (size==0x20)
mem2 == base + 0x201000 (size==0x000100)
mem3 == base + 0x203000 (size==0x000400)
So of course, it is tempting to wonder whether it is really neccessary
to allocate three newbus entities for them. On the other hand, I have
to believe that the BIOS has already set the base and sizes of these
areas, and it would be a really bad idea to pretend that they are a
single (say 3-meg) resource.
I think I will just go ahead with allocating three separate resources
for them, but I would be very interested in other opinions.
Thanks,
-Richard
---
Richard Hodges | Matriplex, inc.
title | 769 Basque Way
[EMAIL PROTECTED] | Carson City, NV 89706
775-886-6477| www.matriplex.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel Hacking (i tried not to make it lame)
[EMAIL PROTECTED] wrote: 2.) you should know some basic stuff about FreeBSD internels (i am planning on getting The Design and Implementation of the 4.4BSD Operating System that is about it the rest really is a blur and is so complex and huge i have no idea where to begin hope i wasn't to lame guys :-) Better start with some books on general OS design. For example, Tannenbaum's or something like this. The 4.4BSD book goes into details expecting that you have the high-level knowledge of things, so without that knowledge it would be very difficult to read. Another prerequisite would be a book on general Unix systems programming, and by the same reason: reading about how things are implemented is much easier if you already know what these things being implemented are. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
capturing an early kernel dump
How do I capture an early kernel dump (before rc executes and sets dumpdev)? The dump partition used to be an option in the kernel config file, but that seems to have changed in 3.X or 4.X. Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
Re: NEWBUS: multiple calls needed?
In message [EMAIL PROTECTED], rh@m atriplex.com writes: I think I will just go ahead with allocating three separate resources for them, but I would be very interested in other opinions. The different regions on a device often have different functionality which may allow/call for different memory access characteristics. For instance, you probably want attempts to write to onboard ROM to fault. You might mark to allow prefetch on large on-device buffers where reads have no side effects. Beyond that, if a specification does not prohibit a behavior eventually you'll run into a system that implements it because it seems to make sense or is just convienant. For example, if I thought about accomodating a systems where virtual and physical addresses matched (the Linux kernel used to do this), I might pad everything to page boundaries and skip a page between entries to make it easier to catch overruns. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
At 7:32 PM +0100 1/26/01, mouss wrote: Hi, I've modified the kernel to add F_CLOSEM functionality to fcntl. (I've seen this in some AIX docs). The purpose is allow a process to close all its filedescriptors starting from a given value without issuing thousands of close() syscalls. This may be used for programs that daemonize themselves (or one of their children) after some amount of work, when many fd's has been opened. The program would simply call fcntl(minclose, F_CLOSEM, 0); The patch concerns /sys/kern/kern_descriptors.c and fcntl.h (and of course the corresponding manpage). Is this functionality worth inclusion in the kernel (or should I throw away the patch)? are there any kind souls to review the patch? In a number of programs, I've seen references to a "closeallfds" routine, which seems to do this. Right now (at 1am), the only program I can think of which did this is 'lpr', and it has it's own implementation of closeallfds. So in that case it isn't a system routine, and it just loops thru getdtablesize() fd's closing them all. On the other hand, I seem to remember this being done (in some other program, if not in lpr) because closeallfds *is* a system routine in some place or another. The intent of closeallfds is the same as what you have implemented, as it is: void closeallfds(int start); While I understand that defining a new routine is more work than just adding a parameter to an existing routine, I do think it is more appropriate to have that new routine than to use fcntl for this. The description for fcntl says the first parameter is: a descriptor to be operated on by 'cmd' as described below. For the proposed F_CLOSEM command, it does not operate on the GIVEN fd, it operates on a whole bunch of OTHER fd's. This means that a program which calls fcntl with a cmd-argument which is different than the programmer thinks is being passed could cause some pretty painful-to-debug errors in sections of the program which have nothing to do with the section that has the bug. Of the various operating systems I use, none of them seem to actually have a closeallfds, but maybe someone else will remember where it comes from. Certainly it would be nice to have this capability implemented somewhere in the system level, where some useful optimization could be done. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
