Re: fdescfs functional in 6.1?
I guess I just expected it to print all character device entries for the file descriptors open by my process. Kind of like the old /dev/fd/1 /dev/fd/2 directories used to be under MAKEDEV... On Fri, Jul 28, 2006 at 11:18:48PM -0500, Dan Nelson wrote: > In the last episode (Jul 28), Jaye Mathisen said: > > devfs is mounted, fdesc is unmounted: > > > > s2# ls -l /dev/fd > > total 0 > > crw-rw-rw- 1 root wheel 250, 0 Jul 25 03:25 0 > > crw-rw-rw- 1 root wheel 250, 1 Jul 25 03:28 1 > > crw-rw-rw- 1 root wheel 250, 2 Jul 25 03:27 2 > > > > Looks just like I think it should. > > > > Then: > > s2# mount -t fdescfs fdescfs /dev/fd > > s2# ls -l /dev/fd > > total 16 > > crw--w 1 root tty 5, 1 Jul 28 18:01 0 > > crw--w 1 root tty 5, 1 Jul 28 18:01 1 > > crw--w 1 root tty 5, 1 Jul 28 18:01 2 > > d-w--- 1 mailnull mailnull 512 Jul 23 00:01 3 > > d- 1 root wheel 512 Jul 25 03:25 4 > > s2# umount /dev/fd > > > > This thing is all over the map.. permissions changed, a *directory* > > for fd's 3 and 4? > > What do you expect ls to open to print a *directory* listing? :) > > fd's 0, 1, and 2 are /dev/tty, and the permissions look fine. > > fd 3 is your current directory (so I guess you're in some smtp-related > directory?), and fd 4 is the directory on the commandline (/dev/fd). > > -- > Dan Nelson > [EMAIL PROTECTED] > > > !DSPAM:44caf09f196113296012617! > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fdescfs functional in 6.1?
In the last episode (Jul 28), Jaye Mathisen said: > devfs is mounted, fdesc is unmounted: > > s2# ls -l /dev/fd > total 0 > crw-rw-rw- 1 root wheel 250, 0 Jul 25 03:25 0 > crw-rw-rw- 1 root wheel 250, 1 Jul 25 03:28 1 > crw-rw-rw- 1 root wheel 250, 2 Jul 25 03:27 2 > > Looks just like I think it should. > > Then: > s2# mount -t fdescfs fdescfs /dev/fd > s2# ls -l /dev/fd > total 16 > crw--w 1 root tty 5, 1 Jul 28 18:01 0 > crw--w 1 root tty 5, 1 Jul 28 18:01 1 > crw--w 1 root tty 5, 1 Jul 28 18:01 2 > d-w--- 1 mailnull mailnull 512 Jul 23 00:01 3 > d- 1 root wheel 512 Jul 25 03:25 4 > s2# umount /dev/fd > > This thing is all over the map.. permissions changed, a *directory* > for fd's 3 and 4? What do you expect ls to open to print a *directory* listing? :) fd's 0, 1, and 2 are /dev/tty, and the permissions look fine. fd 3 is your current directory (so I guess you're in some smtp-related directory?), and fd 4 is the directory on the commandline (/dev/fd). -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fdescfs functional in 6.1?
I will confess, I have on idea if this is what's supposed to be happening. The OpenBSD spam filter system need access to /dev/fd/7. Man page says that I need to mount the fdescfs to get access. Fine. I'm running 6.1-STABLE. So here's what I see, and it looks very odd: devfs is mounted, fdesc is unmounted: s2# ls -l /dev/fd total 0 crw-rw-rw- 1 root wheel 250, 0 Jul 25 03:25 0 crw-rw-rw- 1 root wheel 250, 1 Jul 25 03:28 1 crw-rw-rw- 1 root wheel 250, 2 Jul 25 03:27 2 Looks just like I think it should. Then: s2# mount -t fdescfs fdescfs /dev/fd s2# ls -l /dev/fd total 16 crw--w 1 root tty 5, 1 Jul 28 18:01 0 crw--w 1 root tty 5, 1 Jul 28 18:01 1 crw--w 1 root tty 5, 1 Jul 28 18:01 2 d-w--- 1 mailnull mailnull 512 Jul 23 00:01 3 d- 1 root wheel 512 Jul 25 03:25 4 s2# umount /dev/fd This thing is all over the map.. permissions changed, a *directory* for fd's 3 and 4? SO I can believe that fdescfs is broken, is there some way to create the entries via mknod on bootup, or some entry in the devfs source that will make say through fd 20? Or is it working just like it should, and I should just not worry about it? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
In <[EMAIL PROTECTED]>, Matthew Dillon <[EMAIL PROTECTED]> typed: > There is another solution for FreeBSD folks, however. You *DO* have > four slices to play with. You can put a disklabel with 8 partitions > in it on each one (for 32 total). It isn't as convenient, but it does > work. Um, that's "many" slices. The extended slice can hold as many slices as you want. The OS accessing them may have limits (I don't know if FreeBSD does or not). FreeBSD can put partitions in logical slices, but it can't boot from them. There are other options for those that want them. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
:On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote: :> On Thu, Jul 27, 2006 at 08:39:37AM +0200, Andreas Klemm wrote: :> > Later I wanted to mount the dfly filesystems on FreeBSD 6.1, :> > of course still my main Unix ;-) But it wasn't possible. :> :> DragonFly disklabels allow 16 entries by default, FreeBSD still limits :> it to 8. That's why you can't read it directly. :> : :Hmm, for the sake of compatibility, wouldn't it have been an option, :to add this extra bit to the end of the struct ? : : Andreas /// : :-- :Andreas Klemm - Powered by FreeBSD 6 The thing to note here is that FreeBSD had to make room for the UFS1+UFS2 boot code, so it moved the boot code back to the point where it abuts the 8-partition-sized disklabel. So at least insofar as FreeBSD goes, the partition table cannot be expanded to 16 partitions with UFS1+UFS2 boot code. I'm guessing that it *could* be expanded to 16 partitions with UFS1 only or UFS2 only boot code (assuming the boot code were relocated back to where it was originally in FreeBSD-4/5 times, before UFS2 came along). With regards to simply recognizing a DragonFly partition... yes, that would be easy to do. Since FreeBSD is now devfs-based, the bit we had to steal to support 16 partitions in /dev isn't an issue. I dunno if geom changes the equation any. Personally I have always felt that 8 partitions is restrictive. My main home server has 10 and the main DragonFly box has 11. There is another solution for FreeBSD folks, however. You *DO* have four slices to play with. You can put a disklabel with 8 partitions in it on each one (for 32 total). It isn't as convenient, but it does work. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 5.5 and software timers
M. Warner Losh wrote: : : I replaced libc_r with libpthread and it immediately reboots the system! Neither of these is good! Does it happen on 6? Don't know, I had enough trouble going from 5.4 to 5.5 :-( 6.x might not even run on my hardware. : I am going to try to nail down just what and why this happens and post : that. : (reminder: even if this change happened in 3.4, it didn't affect me till : 5.5) It might be useful to find the change. Warner -- Michael Scheidell, CTO SECNAP Network Security / www.secnap.com [EMAIL PROTECTED] / 1+561-999-5000, x 1131 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New Welcome message for FreeBSD
* Giorgos Keramidas ([EMAIL PROTECTED]) wrote: > >> New motd-welcome message for FreeBSD. > >> > >> http://www.cwt.uz/motd > >> > >> best regards > > I like it! Very good. > I don't. It is pretty "content free" when compared with our current > default motd. I agree, FreeBSD is serious OS, and it's not good idea to add ASCII beastie and other fancy stuff anywhere (not into loader menu, nor into motd). But, if by any chance thing like this happens, I think it's best to make it eye candy as much as possible. For example, `FreeBSD' would look better in anti-aliased way, like this (just an ugly example): .o .ss..ss. .sss. d' d' `b d' `' $ `& $, .ss. .ss. .ss. $ .P ?. $`o $$so d' `' d' `b d' `b $. `*o. $ @ $'$ @D @D $`b `b $.P $ $ q. q. $.P ,. .P $ .* $ $ *ss* *ss* $* ^ss' ?ss*` -- Best regards, Dmitry mailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 5.5 and software timers
On Fri, 28 Jul 2006, M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> "Michael Scheidell" <[EMAIL PROTECTED]> writes: : > -Original Message- : > From: M. Warner Losh [mailto:[EMAIL PROTECTED] : > Sent: Thursday, July 27, 2006 9:39 PM : > To: Michael Scheidell : > Cc: freebsd-hackers@freebsd.org : > Subject: Re: FBSD 5.5 and software timers : : I am going to try to nail down just what and why this happens and : post that. : (reminder: even if this change happened in 3.4, it didn't affect me : till 5.5) It might be useful to find the change. There was a fix for an issue I had with nanosleep() in the past (gnu/77818[1]) that might be related. It went into 5.4-STABLE. Sean 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/77818 -- [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
Maxime Henrion wrote: maksim yevmenkin wrote: Maxime Henrion wrote: Dag-Erling Sm?rgrav wrote: Maksim Yevmenkin <[EMAIL PROTECTED]> writes: so far i only got one (successful) report. would people please give it a try to see if work, so i can commit it. Please commit it. I don't see how it can do any harm. Yes please; I'd like to see this patch in HEAD as soon as possible so that we can have as much coverage as possible since this is the kind of fix that will be very desirable to MFC for 6.2-RELEASE. patch was committed to head yesterday. Yeah, I just saw it, I was quite behind with my mail. Thanks! BTW, does your patch also fix similar problems with kbdmux(4) and the geli mountroot prompt? yes, it should. please let me know if you still have this kind of problems with kbdmux(4) and atkbd(4) Great. I haven't had the time to look at the patch yet, but can you foresee any problem with MFC'ing it or would you consider it safe? i will mfc it in one week (just like the commit comment says). i can mfc it earlier providing that enough people try it and confirm that it fixes the problem. there should be no problem with mfc'ing it, imo. the patch is a minor hack and makes kbdmux(4) explicitly poll slave keyboards in "polled" mode only. thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed: > On Thu, Jul 27, 2006 at 09:33:41PM -0400, Mike Meyer wrote: > > "Small disk drive" means "smaller than any drive I can buy at the > > local Best Buy/Circuit City/CompUSA/similar". At the time, I needed an > > 80GB drive, and paid about $60 for it. > Well then your comparison isn't really fair.. Sure, a brand new hard drive > from a retail outlet is more expensive than a 10-year-old box (especially > if the box is refurbished). Um, I didn't buy the drive from a retail outlet. It was defined as small *because* it's to old and small for the retail outlets to carry it. Yes, it's not as old as the systems I bought, but it's the price point I had. I bought it through a price comparison engine; I'd have to dig through my records to find out who the actual seller was. > No surprise there! I thought we were comparing oranges and oranges. > In that case, check out www.geeks.com (the old computergeeks), they > have a number of drives for sale under $49.95. The oranges we are comparing are "acceptable solutions to wanting to isolate subsystems." The original solution was to buy modern disks, and put lots of partitions on them. My proposed solution is to buy a number of cheap boxes. A cheaper solution (the cheapest?) is to buy lots of small, cheap disks. (and before somebody brings it up, the costs involved only include the up-front cost.) They all have their tradeoffs, but the point I made is that objecting to my solution over the original one because of price doesn't carry that much weight. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
maksim yevmenkin wrote: > Maxime Henrion wrote: > >Dag-Erling Sm?rgrav wrote: > >>Maksim Yevmenkin <[EMAIL PROTECTED]> writes: > >>>so far i only got one (successful) report. would people please give > >>>it a try to see if work, so i can commit it. > >>Please commit it. I don't see how it can do any harm. > > > >Yes please; I'd like to see this patch in HEAD as soon as possible so > >that we can have as much coverage as possible since this is the kind of > >fix that will be very desirable to MFC for 6.2-RELEASE. > > patch was committed to head yesterday. Yeah, I just saw it, I was quite behind with my mail. Thanks! > >BTW, does your patch also fix similar problems with kbdmux(4) and the > >geli mountroot prompt? > > yes, it should. please let me know if you still have this kind of > problems with kbdmux(4) and atkbd(4) Great. I haven't had the time to look at the patch yet, but can you foresee any problem with MFC'ing it or would you consider it safe? Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 5.5 and software timers
In message: <[EMAIL PROTECTED]> "Michael Scheidell" <[EMAIL PROTECTED]> writes: : > -Original Message- : > From: M. Warner Losh [mailto:[EMAIL PROTECTED] : > Sent: Thursday, July 27, 2006 9:39 PM : > To: Michael Scheidell : > Cc: freebsd-hackers@freebsd.org : > Subject: Re: FBSD 5.5 and software timers : : > libc_r depends on absolute system time to do its sleeps and : > timeouts, and has since FreeBSD 3.4. This dependency has : : Could be, but it worked up to and including 5.4. It worked for the one simple test case that you had. I'm not sure what changed between 5.4 and 5.5 to break it. I've hit similar test cases as far back as 3.4. : > been the result of many conversations over time, and has had : > several patches posted. Since libc_r is dead technology, : > there's little chance they will be adopted. : : I replaced libc_r with libthr and two things happen: : One of my threads doesn't run, and it won't die (kill -9 doesn't even : kill it) : : I replaced libc_r with libpthread and it immediately reboots the system! Neither of these is good! Does it happen on 6? : I am going to try to nail down just what and why this happens and post : that. : (reminder: even if this change happened in 3.4, it didn't affect me till : 5.5) It might be useful to find the change. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 09:33:41PM -0400, Mike Meyer wrote: > > "Small disk drive" means "smaller than any drive I can buy at the > local Best Buy/Circuit City/CompUSA/similar". At the time, I needed an > 80GB drive, and paid about $60 for it. Well then your comparison isn't really fair.. Sure, a brand new hard drive from a retail outlet is more expensive than a 10-year-old box (especially if the box is refurbished). No surprise there! I thought we were comparing oranges and oranges. In that case, check out www.geeks.com (the old computergeeks), they have a number of drives for sale under $49.95. > Try http://www.pcretro.com/. Their current special is the Dell > PowerEdge 6350 (dual CPU, 255MB ram, 2 9GB hot swap drives on separate > controllers) for $49.95. The boxes I bought had a mouse and keyboard > included, no monitor or speakers. Not that I cared - I tossed the > mouse and keyboard on the spare parts pile and plugged them into a > KVM. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
Maxime Henrion wrote: Dag-Erling Sm?rgrav wrote: Maksim Yevmenkin <[EMAIL PROTECTED]> writes: so far i only got one (successful) report. would people please give it a try to see if work, so i can commit it. Please commit it. I don't see how it can do any harm. Yes please; I'd like to see this patch in HEAD as soon as possible so that we can have as much coverage as possible since this is the kind of fix that will be very desirable to MFC for 6.2-RELEASE. patch was committed to head yesterday. BTW, does your patch also fix similar problems with kbdmux(4) and the geli mountroot prompt? yes, it should. please let me know if you still have this kind of problems with kbdmux(4) and atkbd(4) thanks, max ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: www/en/projects/ideas index.sgml
Quoting Robert Watson <[EMAIL PROTECTED]> (from Fri, 28 Jul 2006 13:45:50 +0100 (BST)): On Fri, 28 Jul 2006, Alexander Leidinger wrote: BTW, a problem that has occurred a number of times in the past is that people have approached us with implementations of ideas in the idea list that it has later transpired we aren't actually interested in (sometimes at all). I think it might not be a bad idea to sprinkle the My impression is, that we lack some committers which not only have time to review the submissions, but also have the necessary domain specific knowledge at the same time. I suggest marking unreviewed ideas as unreviewed then. My biggest Which isn't entirely true. We filter incoming ideas (we at least rejected one or two... after talking with the submitter), but we aren't able to distinguish good looking but bad ideas from good looking and good ideas. Some ideas are only rejectable by someone with enough domain specific knowledge and look ok for most other people. So when do you think an entry is reviewed? How to determine whom to ask for review and how to get this person interested enough for a review? concern is that we have people who come along, see the idea, implement it, and it's then dropped on the floor because it turns out we didn't really want it, but it was on the list. If we don't want it, we shouldn't list it. If we're not sure if we want it, but think it might be neat, then we should say that's why it's on the list, so as to avoid misunderstandings. I agree. We need some reviewers here... while I'm able to come up with a nice technical description of roughly expressed ideas (as long as I get the idea), I'm not a TRB and as such aren't aware of every implication. And some ideas are expressed in a way which make them sound like it's "common knowledge to people which work in this field" (ATM I refer to the NFS lockd in kernel implementation idea). Given that we can't get the user space code to work and don't have an owner for it (it appears to be abandonware), I think moving it into the kernel would be a disaster. Uhm... I'm withhin the implicit assumption that we first need to fix NFS lockd (an entry before the "move into the kernel" entry)... ok, we need to record dependencies here. So: helping hands are welcome! Thanks for taking some time to review some parts of the list. I'll try to take a look through the rest of them later today. Thanks, Alexander. -- Let me put it this way: today is going to be a learning experience. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: www/en/projects/ideas index.sgml
Quoting Robert Watson <[EMAIL PROTECTED]> (from Fri, 28 Jul 2006 09:52:33 +0100 (BST)): [moving to [EMAIL PROTECTED] feel free to redirect if you think there's a more appropriate list] On Fri, 28 Jul 2006, Joel Dahl wrote: Modified files: en/projects/ideasindex.sgml Log: - Extend the ktrace project with a new task. [1] [adding some warnings to this project] Thanks for reviewing and the heads up regarding problems which may arise. Yes, we should add them to the entry. BTW, a problem that has occurred a number of times in the past is that people have approached us with implementations of ideas in the idea list that it has later transpired we aren't actually interested in (sometimes at all). I think it might not be a bad idea to sprinkle the My impression is, that we lack some committers which not only have time to review the submissions, but also have the necessary domain specific knowledge at the same time. idea list with some additional cautionary language -- often ideas listed there are things to explore, not to adopt without very careful consideration. For example, the "FPU subsystem overhaul", "Process Uhm... the FPU one... ok. AFAIK bde reviewed it. I haven't seen the review (or I don't remember it), but so far it looks like it would be beneficial to commit it (AFAIR). I'm not able to review the code (I lack the necessary domain specific knowledge), but I wanted to give it a try on my system and then send a mail to arch to get some technical reasons why to not commit commit it. Similar for the new TCP checksumming code. Initially there was a problem, it got fixed, and now nobody takes care of it since everyone seems to think "it's flawed". At least this is the impression I got. checkpointing", "Pluggable disk shceduler", "Magic Symlinks", "NFS Lockd (kernel implementation)", and several others -- the task here often isn't to port/write the code, the task is to port/write and then perform a detailed and careful evaluation of the changes to decide whether they are a good idea, and then consider adopting the code only if the evaluation suggests it is a good idea and after significant refinment. So far we got not much responses from committers/developers. There's a lot of interest in working on some of the entries, but so far we don't get much review for the entries/ideas themself. Any refinement is welcome and appreciated. So if someone has some thoughts about specific entries: please, share them with us. Some of the ideas on this list are distinctly "explore this direction as a computer scientist, not a code hacker" sorts of problems -- for example, the "Process checkpointing" task seems to suggest that if you can read the DFBSD repository and write some C code, you're set. In fact, this is not remotely the case. Checkpointing is a very difficult problem in computer science, with little consensus on how it should be done (and indeed whether it should be done at all) by general purpose operating systems. Not only that, but we would not adopt the DFBSD implementation as-is, as it solves a few of the easy problems, and none of the hard ones (i.e., security). The requirements here aren't just the ability to write code, but an understanding of distributed systems, our application/execution model, a strong understanding of the performance and security requirements, and willingness to not just look at code but the extensive research literature on this topic. AFAIR the process checkpointing in DFly has to be enabled (or am I mixing this up with the magic symlinks?) in the kernel. And the man page contains some text what is possible and what not, and about security implications. Yes, they don't use a model which is able to solve all cases, but for some cases where the programs (those which don't make heavy use of I/O and thus can open/close I/O channels when they are needed) are written to make use of this feature, you can make some users happy and the developers can concentrate at the problem at hand. So it's one of those 80/20 solutions. While I agree that a 100% solution would be nice, I think an implementation of this in -current would be nice to have. I think people often grab ideas from the list thinking that if implemented as described, they will get committed, and this is not the case. In many of the sorts of "scientific" cases it's likely we'll look at the results and say, "Oh, that was a bad idea", or maybe slightly more likely, "Oh, hmm, not so sure about that". The existing Joel and I already talked briefly about an "we don't do that" or "been there, done that, wasn't a good idea" page because of this. cautionary language captures that there might be disagreements on the specifics, but fails to capture that there may be disagreements on the fundamental ideas themselves. I like the ideas list idea a lot, and Ok, we should change that. Thanks for providing a big picture view for those of us
RE: FBSD 5.5 and software timers
> -Original Message- > From: M. Warner Losh [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 27, 2006 9:39 PM > To: Michael Scheidell > Cc: freebsd-hackers@freebsd.org > Subject: Re: FBSD 5.5 and software timers > libc_r depends on absolute system time to do its sleeps and > timeouts, and has since FreeBSD 3.4. This dependency has Could be, but it worked up to and including 5.4. > been the result of many conversations over time, and has had > several patches posted. Since libc_r is dead technology, > there's little chance they will be adopted. I replaced libc_r with libthr and two things happen: One of my threads doesn't run, and it won't die (kill -9 doesn't even kill it) I replaced libc_r with libpthread and it immediately reboots the system! I am going to try to nail down just what and why this happens and post that. (reminder: even if this change happened in 3.4, it didn't affect me till 5.5) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: www/en/projects/ideas index.sgml
On Fri, 28 Jul 2006, Alexander Leidinger wrote: BTW, a problem that has occurred a number of times in the past is that people have approached us with implementations of ideas in the idea list that it has later transpired we aren't actually interested in (sometimes at all). I think it might not be a bad idea to sprinkle the My impression is, that we lack some committers which not only have time to review the submissions, but also have the necessary domain specific knowledge at the same time. I suggest marking unreviewed ideas as unreviewed then. My biggest concern is that we have people who come along, see the idea, implement it, and it's then dropped on the floor because it turns out we didn't really want it, but it was on the list. If we don't want it, we shouldn't list it. If we're not sure if we want it, but think it might be neat, then we should say that's why it's on the list, so as to avoid misunderstandings. idea list with some additional cautionary language -- often ideas listed there are things to explore, not to adopt without very careful consideration. For example, the "FPU subsystem overhaul", "Process Uhm... the FPU one... ok. AFAIK bde reviewed it. I haven't seen the review (or I don't remember it), but so far it looks like it would be beneficial to commit it (AFAIR). I'm not able to review the code (I lack the necessary domain specific knowledge), but I wanted to give it a try on my system and then send a mail to arch to get some technical reasons why to not commit commit it. Similar for the new TCP checksumming code. Initially there was a problem, it got fixed, and now nobody takes care of it since everyone seems to think "it's flawed". At least this is the impression I got. I have no specific technical opinion on either of these items. Some of the ideas on this list are distinctly "explore this direction as a computer scientist, not a code hacker" sorts of problems -- for example, the "Process checkpointing" task seems to suggest that if you can read the DFBSD repository and write some C code, you're set. In fact, this is not remotely the case. Checkpointing is a very difficult problem in computer science, with little consensus on how it should be done (and indeed whether it should be done at all) by general purpose operating systems. Not only that, but we would not adopt the DFBSD implementation as-is, as it solves a few of the easy problems, and none of the hard ones (i.e., security). The requirements here aren't just the ability to write code, but an understanding of distributed systems, our application/execution model, a strong understanding of the performance and security requirements, and willingness to not just look at code but the extensive research literature on this topic. AFAIR the process checkpointing in DFly has to be enabled (or am I mixing this up with the magic symlinks?) in the kernel. And the man page contains some text what is possible and what not, and about security implications. Yes, they don't use a model which is able to solve all cases, but for some cases where the programs (those which don't make heavy use of I/O and thus can open/close I/O channels when they are needed) are written to make use of this feature, you can make some users happy and the developers can concentrate at the problem at hand. So it's one of those 80/20 solutions. While I agree that a 100% solution would be nice, I think an implementation of this in -current would be nice to have. It's a neat/fun hack, but I would object strongly to the current implementation going into the tree. I think 80/20 is a mischaracterization. We need some reviewers here... while I'm able to come up with a nice technical description of roughly expressed ideas (as long as I get the idea), I'm not a TRB and as such aren't aware of every implication. And some ideas are expressed in a way which make them sound like it's "common knowledge to people which work in this field" (ATM I refer to the NFS lockd in kernel implementation idea). Given that we can't get the user space code to work and don't have an owner for it (it appears to be abandonware), I think moving it into the kernel would be a disaster. We've been discussing ripping out the current user space code entirely on the basis that it is responsible for a huge number of bug reports and lots of problems. So: helping hands are welcome! Thanks for taking some time to review some parts of the list. I'll try to take a look through the rest of them later today. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Use ddb(4)?
Dag-Erling Sm?rgrav wrote: > Maksim Yevmenkin <[EMAIL PROTECTED]> writes: > > so far i only got one (successful) report. would people please give > > it a try to see if work, so i can commit it. > > Please commit it. I don't see how it can do any harm. Yes please; I'd like to see this patch in HEAD as soon as possible so that we can have as much coverage as possible since this is the kind of fix that will be very desirable to MFC for 6.2-RELEASE. BTW, does your patch also fix similar problems with kbdmux(4) and the geli mountroot prompt? Cheers, Maxime ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
