Re: cause of reboot
On 9/30/13 11:08 PM, Jason Hellenthal wrote: Also . . . grep -ri . . . On Sep 30, 2013, at 11:06, Jason Hellenthal jhellent...@dataix.net wrote: And /etc/ ? And /var/cron ? On Sep 30, 2013, at 11:00, Emre Çamalan mail...@yandex.com wrote: Yes I checked also it , such as ; grep -i 'reboot' /root/scripts/* -R grep -i 'halt' /root/scripts/* -R grep -i 'shutdown' /root/scripts/* -R 30.09.2013, 17:33, Jason Hellenthal jhellent...@dataix.net: Did you check for the command reboot in all of the periodic scripts and cron jobs as well as the command shutdown ? On Sep 30, 2013, at 10:24, Emre Çamalan mail...@yandex.com wrote: Hi, my server reboots every night and same o'clock last 10 days. But this machine's uptime was 96days. Suddenly reboot this machine and now this continue every night again and again. I didn't find any reason and I didn't change anything else. I looked last command, reboot ~ ~ AM 03.15 ~ I checked dmesg -a , it has only generic things no other things. I checked /var/log/messages I wrote script and checked swapinfo , cpu and memory but all of them was normal before reboot. I checked crontab and scripts. I checked crashinfo but no dump from kernel. I didn't find any useful info from this commands. I checked praudit /var/audir/20130930..CrashRecovery and I didn't understand very well from this file but I think this means my machine crash and reboot isn't it?? And How can I understand what is the reason of rebooting my FreeBSD8.3 server. Please help I need to find cause of reboot.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org Firstly, does this machine have the kernel debugger installed? if not then a kernel page fault will look like a reboot. if you know when this is going to occur, then I suggest that you set up some logging of every new process run, to a second machine, or possibly you might just ssh int the machine and leave 'top' running when it reboots you shoud get a snapshot of what's going on. you could just rename 'reboot' and see if it still happens. If not, then replace reboot (and friends) with a script that reports who called it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: weekly periodic security status
On 8/25/13 7:05 PM, Jeremie Le Hen wrote: And the following variables to control whether you want each check to run daily, weekly or directly from crontab (the default, backward compatible values are shown): security_status_chksetuid_enable=daily security_status_neggrpperm_enable=daily security_status_chkmounts_enable=daily security_status_chkuid0_enable=daily security_status_passwdless_enable=daily security_status_logincheck_enable=daily security_status_chkportsum_enable=NO security_status_ipfwdenied_enable=daily security_status_ipfdenied_enable=daily security_status_pfdenied_enable=daily security_status_ipfwlimit_enable=daily security_status_ipf6denied_enable=daily security_status_kernelmsg_enable=daily security_status_loginfail_enable=daily security_status_tcpwrap_enable=daily excellent.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Stacking lots of IP's on a single box - any 'gotchas'?
On 7/31/13 5:37 PM, Karl Pielorz wrote: Hi, We've got a number of boxes we'd like to consolidate - this could mean upward of 1,500 IP's on a single box (9.1 amd64). Last time we did anything like this we hit at issue at around 900 (ntpd 'binds' by default to all available IP's - I think we had a workaround for that). But is there any hard limit we're likely to encounter putting so many IP's on a single machine? - Are there any limits that would likely need tuning to support that many IP's? all on one interface? do you really need so many addresses? what are you trying to achieve? you can make a machine accept work for many addresses without actually assigning those addresses to any interface on the machine (see ipfw fwd) Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Stacking lots of IP's on a single box - any 'gotchas'?
On 8/1/13 4:27 AM, Diane Bruce wrote: On Wed, Jul 31, 2013 at 11:47:02PM +0400, Sergey Kandaurov wrote: On 31 July 2013 13:37, Karl Pielorz kpielorz_...@tdx.co.uk wrote: Hi, We've got a number of boxes we'd like to consolidate - this could mean upward of 1,500 IP's on a single box (9.1 amd64). Last time we did anything like this we hit at issue at around 900 (ntpd 'binds' by default to all available IP's - I think we had a workaround for that). This is because select() has a limit on FD_SETSIZE (1024). If it tries to select 1024 fds, bad things could happen. Newer ntpd (not in base) has a feature to bind only to the specific interface; this was used to run ntpd on boxes with 1200 IPs on 1 i/face. I can tell you from experience that FreeBSD has no problems at all selecting on more than 1024 fds. In fact, this is what I would suggest you do. Your limit then is going to be the number of anonymous ports on each IP. Figure 32000 or so to be conservative that's more than what you need. Once again. I ask: Why do you want to do this? if you just want to respond to a small number of ports on multiple addresses there are easier ways to do this with a single socket. But is there any hard limit we're likely to encounter putting so many IP's on a single machine? - Are there any limits that would likely need tuning to support that many IP's? Unlikely, besides those unrelated things like ntpd+select() et.al. -- wbr, pluknet - Diane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Kernel dumps [was Re: possible changes from Panzura]
On 7/12/13 10:01 PM, Ed Maste wrote: On 10 July 2013 19:07, Vincent Hoffman vi...@unsane.co.uk wrote: There was some work on something similar at one point, not sure what came of it. http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020164.html The code referenced there has been used in production since 2005 or so, and is based on an earlier implementation for FreeBSD 4.x that dates to 2000. Despite some shortcomings in the implementation it has proved quite reliable in practice. It hasn't made it into the tree yet for reasons raised in this thread. The primary issue is that it allocates mbufs in the packet sending path, and so relies on a number of kernel subsystems to be in a consistent state. It doesn't use the stack, routing table, or driver interrupt interfaces though. It could likely be made committable with a relatively small effort to switch to preallocating an mbuf+cluster or two at configuration time. More information is on the FreeBSD wiki, at https://wiki.freebsd.org/Netdump I would say this is one of the features I've looked for a LOT over the last 20 years. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Kernel dumps [was Re: possible changes from Panzura]
On 7/11/13 6:09 AM, Kevin Day wrote: Those sound useful. Just out of curiosity, however, since we're on the topic of kernel dumps: Has anyone even looked into the notion of an emergency fall-back network stack to enable remote kernel panic (or system hang) debugging, the way OS X lets you do? I can't tell you the number of times I've NMI'd a Mac and connected to it remotely in a scenario where everything was totally wedged and just a couple of minutes in kgdb (or now lldb) quickly showed that everything was waiting on a specific lock and the problem became manifestly clear. The feature also lets you scrape a panic'd machine with automation, running some kgdb scripts against it to glean useful information for later analysis vs having to have someone schlep the dump image manually to triage. It's going to be damn hard to live without this now, and if someone else isn't working on it, that's good to know too! I could imagine that we could stash away a vimage stack just for this purpose. yould set it up on boot and leave it detached until you need it. you just need to switch the interfaces over to the new stack on panic and put them into 'poll' mode. Or maybe you'd need more (like pre-allocating mbufs for it to use). Just an idea. At a previous employer, we had a system where on a panic it had a totally separate stack capable of just IP/UDP/TFTP and would save its core via TFTP to a server. This isn’t as nice as full remote debugging, but it was a whole lot easier to develop. The caveats I remember were: 1) We didn’t want to implement ARP, so you had to write the mac address of the “dump server” to the kernel via sysctl before crashing. 2) We also didn’t want to have to deal with routing tables, so you had to manually specify what interface to blast packets out to, also via sysctl. 3) After a panic we didn’t want to rely on interrupt processing working, so it polled the network interface and blocked whenever it needed to. Since this was an embedded system, it wasn’t too big of a deal - only one network driver had to be hacked to support this. Basically a flag that would switch to “disable normal processing, switch to polled fifos for input and output” until reboot. 4) The whole system used only preallocated buffers and its own stack (carved out from memory on boot) so even if the kernel’s malloc was trashed, we could still dump. I’m not sure this really would scratch your itch, but I believe this took me no more than a day or two to implement. Parts #1 and #2 would be pretty easy, but I’m not sure how generic the kernel could support an emergency network mode that doesn’t require interrupts for every network card out there. Maybe that isn’t as important to you as it was to us. The whole exercise is much easier if you don’t use TFTP but a custom protocol that doesn’t require the crashing system to receive any packets, if it can just blast away at some random host oblivious if it’s working or not, it’s a lot less code to write. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
possible changes from Panzura
I'm going through all the internal changes my current employer has made, categorizing them into proprietary and can feed back to FreeBSD. I will probably send out emails like this several times seeking feedback on whether a particular patch is considered useful or not.. these are verse 8.0 at the moment. (this is part of our effort to upgrade) My first candidates are: -internal commit message Add support for dumping kernel dumps in addition to text dumps for kernel panics. Add a new version of savecore to the tree, which knows how to retrieve and save both dumps. Control the new dump behavior via the debug.kerneldump_requested sysctl - disabling this wil go back to the old text dump-only behavior. -- part 2 - Have savecore be more optimistic about saving compressed cores - always try, and only bail if we actually run out of space. The pessimistic only try saving if we've got enough free space to handle the entire dump uncompressed made it too easy for us to run out of space on our /var/crash partition --- Julian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Announcing: nuOS 0.0.9.1b1 - a whole NEW FreeBSD distro, NOT a fork
On 7/9/13 6:12 AM, Teske, Devin wrote: On Jul 8, 2013, at 11:43 AM, Chad J. Milios wrote: We also had to put one file into the etc directory on the / beneath the /etc mount so that /sbin/init can read it before /etc is mounted. There were two or three ways we could do that and each has a tradeoff. I've been bitten by that. Getting access to that file that's beneath once you've booted the system can be ... less than easy. if it's hardlinked to another copy that is not beneath then you can just edit it. I once had a system at vicor where I had a temporary beneath /etc that had all its files linked to files of the same name in /etc.boot/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: expanding amd64 past the 1TB limit
On 6/27/13 12:11 AM, Chris Torek wrote: [...] them (but I still needed the map I drew of the page tables...). care to share? :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Logging natd translations
On 5/15/13 9:52 PM, Daniel Eischen wrote: On Wed, 15 May 2013, Daniel Eischen wrote: We need to log all translations from internal IP addresses to external addresses. It's good enough to have IPv4 to Ipv4 translations for TCP streams, just one log for the start of each stream. We're using FreeBSD-9.1-stable and IPFW with userland natd. The -log option of natd just seems to log statistics, not any translation information. I can't see any easy way to do this with ipfw's rule log option either. Any ideas? To answer my own question, it looks like I can add an ipfw rule such as: divert natd log tcp from INSIDE_NET to any OUTSIDE_NET setup and that basically gives me what I want. why not turn on the logging on natd? I think it has an option for logging new sessions.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Managing userland data pointers in kqueue/kevent
On 5/13/13 2:44 PM, Paul LeoNerd Evans wrote: On Mon, 13 May 2013 11:23:45 -0700 Adrian Chadd adr...@freebsd.org wrote: Just as a data point, I managed 50,000 + connections, at 5,000 + a second, doing a gigabit + of traffic, mid-2000s, with the userland management of all of the socket/disk FD stuff. The biggest overhead at the time was actually the read/write copyin/copyout, NOT the locking overhead of managing this stuff. Why? Because I architected the HTTP side of things to specifically pin FDs to threads, and not allow arbitrary threads to deal with arbitrary FDs. This removed the need for almost all of the state locking that people are concerned about here. I think then this comes from different experiences. I'm guessing this application was: a) Written in C b) Entirely filled with identically-typed identical-purpose file descriptors c) Didn't really use any EV_ONESHOT events d) Didn't close sockets apart from when it received EOF and perhaps most importantly e) Was entirely self-contained - did everything from one unified block of source code. I.e. a very simple set of semantics. I'll explain the situation that I had. The reason I ran into the problem needing EV_DROPWATCH/EV_DROPPED was because I was trying to fix Perl's IO::KQueue. IO::KQueue tries to wrap kqueue/kevent for Perl, allowing the userland Perl code to store an arbitrary Perl data pointer in the udata field. This data is reference-counted. Userland might let the kernel store the only copy of that data, because it comes back in event notifications anyway. Because of this, the reference count has to be artificially incremented to account for the extra pointer in the kernel. Without knowing when the kernel will decide to drop that pointer, I never know when I should decrement the refcount myself. It has no knowledge of what userland is doing with this. It can't know when userland might be EV_ONESHOT'ing. It doesn't really know what events will be oneshot anyway (such as the process exit watches). Finally, it has no idea what other modules are going to call close() on it. This final problem was the real killer - while the first two -could- be worked around with more complex code structures, not knowing what other CPAN modules will ever call close() makes it impossible to handle. Simply asking every CPAN module to please just call fd_close() instead of close() doesn't work here. As compared: having the kernel tell userland when it calls knote_drop() is much simpler. It knows exactly when it is doing this, so simply pushing an event up to userland to tell it it did so is simple. If any more cases than the three known (EV_ONESHOT or other single-shot events; EV_DELETE, close()) are added, userland - and in particular, the IO::KQueue module, will not need updating. It will continue to decrement refcounts and free data perfectly happily when kernel has dropped the watch. I've used this pattern before in C libraries + higher-level language wrappers, and found it to be nicely simple to both implement and use. Because it follows the -same- event notification path that userland is already using, it manages to avoid quite a number of the race-conditions that a secondary, separate data structure and locking often runs into; e.g. if userland is trying to add a new thing into it just at the time there's a notification in-flight from the kernel about an old thing that it used to have. Principly - the fact that kernel tells -userland- about the delete, means that it can atomically *guarantee* that this *will* be the last event about this particular item. Userland must not delete its own data structure about it until this notification happens. If it does this, lots of semantics become a lot simpler. I was responsible for the u_data field. It was not in the original design that was proposed and I suggested it to Jonathan. I was thinking purely of a simple way for an event to supply added information to its handler that would obviate the need for the app to keep complicated tracking structures. I was not thinking in terms of badly behaved (sic) third party high level ops using it through a language binding. I admit that I did not think about the close issue at that time. Your suggested changes are not unreasonable however we could do with more discussion. The point about tracking objects that may be arbitrarily destroyed without the framework being notified is valid and aligns well with general robustness principals. I would suggest that one answer would be to create an extension to register a kevent to catch these events.. (the knote_drop()) The returned event could have all the appropriate information for the event being dropped.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A problem with alq module!
On 5/12/13 11:37 PM, Computer Network Man wrote: Dear Guys; In a fresh FreeBSD 9 or 9.1 Release if you just run these commands: # kldload alq # kldunload alq # init 0 or shutdown -p now it will panic! maybe it's a bug. We have a module which uses alq API's. MODULE_DEPEND(mymodule, alq, 1, 1, 1) when our module starts, loads alq. and when it stops, unloads alq. So after starting and stoping our module and shutdown, we have panic. any opinion in this regard would be appreciated. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org without looking at it, I am guessing that the alq module may mis-register for shutdown notification... (and not undo it).. UTSL please register a bug and include some debugging information ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: MADV_FREE and wait4 EFAULT
On 4/19/13 5:51 AM, Carl Shapiro wrote: On Wed, Apr 17, 2013 at 1:21 AM, Konstantin Belousov kostik...@gmail.comwrote: Did you ensured with e.g. ktrace and procstat -v that your assumptions hold, i.e. the addresses supplied as wait4(2) arguments are valid ? Please provide the minimal test case demonstrating the behaviour. Yes. I instrumented my code to check for a wait4 failure, print the addresses of the status and rusage arguments, and dump the contents of /proc/curproc/map. The addresses of the status and rusage arguments are always in the range of a mapping and marked as read write. I have yet to distill the failure to a minimal test case. The test case I do have is the test harness for the Go language. After running for about 45 minutes I can observe a failure. I have been working to produce something smaller and faster. MADV_FREE should only result in the possible lost of the previous content of the page, not in the faulting of the page access. From the inspection of the code, I do not see how MADV_FREE could result in the memory address becoming invalid. I see. What has lead us to believe this might be an issue with page faults is that writing zeroes to the page with memset before passing it to wait4 makes the error go away. Do you have any advice about how one might go about instrumenting wait4 to generate more information about a failed copyout? Are tools such as dtrace useful in these situations or might it be too invasive? Because of the protracted test cycle and my lack of knowledge in this area, conducting experiments is quite painful at the moment. looks like a great example of something that dtrace should be able to help with. basically you can do a speculative dump of the stuff going on before the copyout and just store it in the case where the copyout fails. I'm just learning getting my dtrace training wheels but I think it may be able to give you what you need. Thanks, Carl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Need advice on sys5 shm and zero copy sockets
On 2/8/13 4:22 AM, gary mazzaferro wrote: Hi, I was told to post this question here (Ken Merry), it would be a good place to get some help. I'm not sure this is doable without a kernel module, which I don't want to add. I'll explain what I'm attempting.. I'm designing a high speed rest motor for cloud execution environment. 1) I'd like to eliminate copy from the tcp stack to the application(s). 2) I'm also sharing the buffers across processes and jails. So I'd like to preserve the zero-copy in a msg pipe/unix socket 3) Some buffers will go to disk file systems. Wish list: 4) I'd like it to work with sctp because I like it for local networking :) 5) I'd like to provision memory pools on a per application/connection/ip port basis. Ultimate Goal: 6) Additionally, I'm injecting code from a foreign process into the workflow of another process (state machine). The connection between them will be a signal and shared state information. I'm assuming item (6) is a separate issue, but it may impact the direction.. I've tried shm with zero copy sockets with linux and it just will not work !! BTW, I'm returning to freebsd after far too many years cheers, gary ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org this sound somewhat like what I did back in the 90s with BSD4.3 unfortunately it was not done with TCP (or sctp of course) what we did was to create a special shared memeory device driver. Then we added ioctls to the disk driver layer to write named blocks of memory from that device to the raw device (we didin't use a filesystem). We also changed the network drivers to use named blocks of memory in that device for packet reception. We added a special protocol which used recvmsg() and and sendmesg() to pass ownership of those named blocks between the process that had mmapped them and the protocol. The protocol had an IP header but also a small protocol specific header of our own.. we sent packets that were larger than a page. zero copy from disk-process, process-network and network-disk (and reverse of course) of course it was all on proprietary protocols so not of use to you. julian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Need advice on sys5 shm and zero copy sockets
On 2/8/13 4:22 AM, gary mazzaferro wrote: Hi, I was told to post this question here (Ken Merry), it would be a good place to get some help. I'm not sure this is doable without a kernel module, which I don't want to add. I'll explain what I'm attempting.. I'm designing a high speed rest motor for cloud execution environment. 1) I'd like to eliminate copy from the tcp stack to the application(s). 2) I'm also sharing the buffers across processes and jails. So I'd like to preserve the zero-copy in a msg pipe/unix socket 3) Some buffers will go to disk file systems. Wish list: 4) I'd like it to work with sctp because I like it for local networking :) 5) I'd like to provision memory pools on a per application/connection/ip port basis. Ultimate Goal: 6) Additionally, I'm injecting code from a foreign process into the workflow of another process (state machine). The connection between them will be a signal and shared state information. I'm assuming item (6) is a separate issue, but it may impact the direction.. I've tried shm with zero copy sockets with linux and it just will not work !! BTW, I'm returning to freebsd after far too many years cheers, gary ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org this sound somewhat like what I did back in the 90s with BSD4.3 unfortunately it was not done with TCP (or sctp of course) what we did was to create a special shared memeory device driver. Then we added ioctls to the disk driver layer to write named blocks of memory from that device to the raw device (we didin't use a filesystem). We also changed the network drivers to use named blocks of memory in that device for packet reception. We added a special protocol which used recvmsg() and and sendmesg() to pass ownership of those named blocks between the process that had mmapped them and the protocol. The protocol had an IP header but also a small protocol specific header of our own.. we sent packets that were larger than a page. zero copy from disk-process, process-network and network-disk (and reverse of course) of course it was all on proprietary protocols so not of use to you. julian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Scrolling in framebuffer syscons
On 2/19/13 11:57 AM, Phileas Fogg wrote: Oleksandr Tymoshenko wrote: On 2/16/2013 5:20 AM, Phileas Fogg wrote: Hi, i have a question about how the scrolling in a framebuffer syscons works. I'm trying to speed up the syscons on the PS3 console which is a simple framebuffer syscons. It uses the renderer _gfbrndrsw_ (see dev/syscons/scgfbrndr.c) to draw into the framebuffer of the PS3 console. The _gfb_draw_ function implements a simple scrolling that moves data from bottom to top with _vidd_copy_. And that's where i have a problem because _vidd_copy_ calls the function _ps3fb_copy_ (see powerpc/ps3/ps3_syscons.c). But the function _ps3fb_copy_ is NOT implemented yet. So, the question is how does the scrolling work then ? I took a look at other syscons implementation based on a framebuffer, and almost all of them do NOT implement _vidd_copy_ function, e.g. XBOX syscons. I think driver re-renders whole screen character by character. That's why no copy operation is invoked. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org You are right, syscons is using the teken terminal emulator which implements scrolling in software. The vidd_copy callback is never called. To optimize the PS3 syscons driver, i have to speed up vidd_puts and vidd_putc callbacks. not sure if it's relevent, but remember that updating the screen mor ethan 50 times a second is pointless. I'm not sure if the curent video console does it but having the final copy only done on 50Hz ticks can save a lot of copying. regards ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting the current thread ID without a syscall?
On 1/15/13 4:03 PM, Trent Nelson wrote: On Tue, Jan 15, 2013 at 02:33:41PM -0800, Ian Lepore wrote: On Tue, 2013-01-15 at 14:29 -0800, Alfred Perlstein wrote: On 1/15/13 1:43 PM, Konstantin Belousov wrote: On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote: Luckily it's for an open source project (Python), so recompilation isn't a big deal. (I also check the intrinsic result versus the syscall result during startup to verify the same ID is returned, falling back to the syscall by default.) For you, may be. For your users, it definitely will be a problem. And worse, the problem will be blamed on the operating system and not to the broken application. Anything we can do to avoid this would be best. The reason is that we are still dealing with an optimization that perl did, it reached inside of the opaque struct FILE to do nasty things. Now it is very difficult for us to fix struct FILE. We are still paying for this years later. Any way we can make this a supported interface? -Alfred Re-reading the original question, I've got to ask why pthread_self() isn't the right answer? The requirement wasn't I need to know what the OS calls me it was I need a unique ID per thread within a process. The identity check is performed hundreds of times per second. The overhead of (Py_MainThreadId == __readgsdword(0x48) ? A() : B()) is negligible -- I can't say the same for a system/function call. (I'm experimenting with an idea I had to parallelize Python such that it can exploit all cores without impeding the performance of normal single-threaded execution (like previous-GIL-removal attempts and STM). It's very promising so far -- presuming we can get the current thread ID in a couple of instructions. If not, single-threaded performance suffers too much.) TLS? Trent. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On 1/9/13 7:21 AM, Richard Sharpe wrote: On Tue, 2013-01-08 at 09:20 -0800, Adrian Chadd wrote: On 8 January 2013 08:15, Richard Sharpe rsha...@richardsharpe.com wrote: On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: .. or you could abstract it out a bit and use freebsd's aio_waitcomplete() or kqueue aio notification. It'll then behave much saner. Yes, going forward that is what I want to do ... this would work nicely with a kqueue back-end for Samba's tevent subsystem, and if someone has not already written such a back end, I will have to do so, I guess. Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want to! (Then, convert parts of samba over to use grand central dispatch... :-) Seriously though - I was doing network/disk IO using real time signals what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + waitcomplete is just brilliant. kqueue for signal delivery is also just brilliant. Just saying. The problem with a fully event-driven approach is that it will not work, it seems to me. Eventually, you find something that is not async and then you have to go threaded. (Because handling multiple clients in one process is very useful and you do not want client-A's long-running op preventing client-B's short-running op from being serviced.) Then, you run into problems like Posix's insistence that all threads in a process must use the same credentials (ie, uid and gids must be the same across all threads), although there is a hack on Linux to work around this behind glibc's back. The best implementation of an async framework I've seen is the one that Alan Cox and friends wrote in the code they sold to IronPort/Cisco. It'd be nice if we could get that extracted out and donated/included into something generally available.. even had a #ifdef Linux code path.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: old style kernel configuration
On 11/22/12 1:17 PM, Garrett Cooper wrote: On Wed, Nov 21, 2012 at 5:58 PM, Eitan Adler li...@eitanadler.com wrote: I've been working on removing obsolete information various documents. While going through older articles I noticed a few references to the old style kernel configuration involving running config(1) manually. Is there any value in keeping this documented as an alternative to make buildkernel or should it be treated as an implementation detail? For new/non-advanced users, this shouldn't necessarily be exposed except as an implementation detail and a historical artifact; more directions, not less serve to confuse the masses - see git as a perfect example of this with all of its workflows. I think the question that should be asked first is: who's your target audience (remember, hackers are generally the more and not less advanced target audience)? Once this question can be answered, I think it would become apparent either to you and other reviewers what the text should say. The canonical way to build a kernel on its own is using config(8). The Makefile acts as a convenient wrapper for this when you want to make a kernel as part of a build, or to redo a kernel that was a part of a build. nearly all kernel developers I know use the config method, and it's widly known and documented. it is however a good way to get mismatching kernel and userland but that's not what we are discussing. Julian Thanks, Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: old style kernel configuration
On 11/21/12 5:58 PM, Eitan Adler wrote: I've been working on removing obsolete information various documents. While going through older articles I noticed a few references to the old style kernel configuration involving running config(1) manually. Is there any value in keeping this documented as an alternative to make buildkernel or should it be treated as an implementation detail? I still do it quite often ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Memory reserves or lack thereof
On 11/12/12 3:49 PM, Adrian Chadd wrote: On 12 November 2012 15:26, Alan Cox a...@rice.edu wrote: On 11/12/2012 5:24 PM, Adrian Chadd wrote: .. wait, so what exactly would the difference be between M_NOWAIT and M_WAITOK? Whether or not the allocation can sleep until memory becomes available. Ok, so we're still maintaining that particular behaviour. Cool. no mem | mem avail -- M_WAITOK | wait, then success |success | -- M_NOWAIT | returns failure|success | -- the question is whether the top left can ever fail for any other reason. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
On 10/22/12 7:12 AM, Adrian Chadd wrote: On 22 October 2012 03:08, Marko Zec z...@fer.hr wrote: The only option I can think of now is to update all of the hotunpluggable device_detach() handlers to do CURVNET_SET(ifp-if_vnet) before calling further down into the networking stack, because as you already observed, whatever triggers a device_detach() handler is not aware of the nature of the driver. Right. Well, since most things are in theory hotpluggable these days (or soon will be, with pcie hotplug), I think we need a slightly more generic solution. (how the hell does this work for devices attached at probe time? What vnet context do they have, and why doesn't the kernel panic there?) Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). Similarly, curvnet is set to vnet0 during kldload events. .. like this. The trouble is going to be handling unplug and kldunload events too. Does curvnet - vnet0 during kldunload events? I think in unload events we probably need to cycle through all vnets and do individual shutdowns of anything that is set up on that vnet.. (but I'm not reading the code to say that, it's possible to ignore me safely) Thanks, Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cpu_spinwait in cngetc
On 9/22/12 10:46 AM, Andriy Gapon wrote: on 18/09/2012 16:25 Andriy Gapon said the following: (Why[*]) Would anyone object to a change like this? diff --git a/sys/kern/kern_cons.c b/sys/kern/kern_cons.c index 5346bc3..d17846a 100644 --- a/sys/kern/kern_cons.c +++ b/sys/kern/kern_cons.c @@ -384,7 +384,7 @@ cngetc(void) if (cn_mute) return (-1); while ((c = cncheckc()) == -1) - ; + cpu_spinwait(); if (c == '\r') c = '\n'; /* console input is always ICRNL */ return (c); [*] :-) I would to re-ping with this question. Is there any architecture where a cpu_spinwait could cause a surprise? Or is universally safe? The most visible place which this change can affect is ddb prompt. looks like the right thing to do ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [maybe spam] Re: FreeBSD 1.x Binaries Work Except under Chroot
On 8/14/12 6:07 AM, Konstantin Belousov wrote: On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote: On 8/13/12 3:33 PM, Dan Plassche wrote: Konstantin, My apologies for any confusion. Your patch solved the problem on 8.2. Static and dynamic a.out binaries from 1.1.5.1 are working normally in a chroot environment now. you will also have to change PID_MAX (spelling?) to be 6 I have considered making this a tunable.. If you don't then the shell in the 1.1.5.1 environment will not be able to handle when a child get s a pid of 16 bits and it will not be able to wait on it. so it will suspend for ever. teh result is that you can not complete a make world. last time I tried a make world completed in about 1 minute and a kernel (1.1.5.1 GENERIC) compiled in way less than a minute. that was in 7.x days. I'd like to see results under 9.2 on a modern machine. I committed today a batch of changes that allowed me to run most of the binaries from 1.1.5.1 CD on real amd64 machine. Below is the pid_max tunable patch. I first thought that it cannot be made a writeable sysctl, but then realized that there is nothing wrong with having existing process pid be greater then pid_max, as far as it is less then PID_MAX. cool.. One thing that may be doing is to have pid_max either inherrited from a parent or jail or somehow influenced by the exec handler.. or (I know adrian suggested this too.) for example if you have an ancestor that is an old a.out image then maybe the system could do the right thing. it wouldn't be able to handle it's OWN pid maybe, but it could handle children. hmm maybe that isn't such a good idea... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [maybe spam] Re: FreeBSD 1.x Binaries Work Except under Chroot
On 8/15/12 3:29 AM, Julian Elischer wrote: On 8/14/12 6:07 AM, Konstantin Belousov wrote: On Mon, Aug 13, 2012 at 06:28:46PM -0700, Julian Elischer wrote: On 8/13/12 3:33 PM, Dan Plassche wrote: Konstantin, My apologies for any confusion. Your patch solved the problem on 8.2. Static and dynamic a.out binaries from 1.1.5.1 are working normally in a chroot environment now. you will also have to change PID_MAX (spelling?) to be 6 I have considered making this a tunable.. If you don't then the shell in the 1.1.5.1 environment will not be able to handle when a child get s a pid of 16 bits and it will not be able to wait on it. so it will suspend for ever. teh result is that you can not complete a make world. last time I tried a make world completed in about 1 minute and a kernel (1.1.5.1 GENERIC) compiled in way less than a minute. that was in 7.x days. I'd like to see results under 9.2 on a modern machine. I committed today a batch of changes that allowed me to run most of the binaries from 1.1.5.1 CD on real amd64 machine. Below is the pid_max tunable patch. I first thought that it cannot be made a writeable sysctl, but then realized that there is nothing wrong with having existing process pid be greater then pid_max, as far as it is less then PID_MAX. cool.. One thing that may be doing is to have pid_max either inherrited from a parent or jail or somehow influenced by the exec handler.. or (I know adrian suggested this too.) for example if you have an ancestor that is an old a.out image then maybe the system could do the right thing. it wouldn't be able to handle it's OWN pid maybe, but it could handle children. hmm maybe that isn't such a good idea... so kib: so when you have it all working, time a make world for us! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD 1.x Binaries Work Except under Chroot
On 8/13/12 3:33 PM, Dan Plassche wrote: Konstantin, My apologies for any confusion. Your patch solved the problem on 8.2. Static and dynamic a.out binaries from 1.1.5.1 are working normally in a chroot environment now. you will also have to change PID_MAX (spelling?) to be 6 I have considered making this a tunable.. If you don't then the shell in the 1.1.5.1 environment will not be able to handle when a child get s a pid of 16 bits and it will not be able to wait on it. so it will suspend for ever. teh result is that you can not complete a make world. last time I tried a make world completed in about 1 minute and a kernel (1.1.5.1 GENERIC) compiled in way less than a minute. that was in 7.x days. I'd like to see results under 9.2 on a modern machine. Julian On Sat, Aug 11, 2012 at 2:45 PM, Konstantin Belousov kostik...@gmail.com wrote: Why did you stripped the public list from the Cc: ? I must have clicked on reply instead of reply all by accident. I sent a copy to the list about 10 minutes after replying to you, when I realized the mistake. You should have mentioned that it is only _some_ binaries which are affected, since I was not able to reproduce your issue at all with /bin/sh or /bin/ls in chroot. It took me a while to realize that you specifically shown the trace for basename. Sorry, I was focusing on the loader problem and left out the root binaries because they were traditionally static. Thanks for your help, Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [maybe spam] Published paper
On 8/7/12 5:24 PM, ali mousa wrote: Hi, I have recently published a paper related to Operating System, can you please check it out http://www.ijcsi.org/papers/IJCSI-9-4-1-77-84.pdf and tell me your opinion, looking forward to hear from you ? Certainly interesting.. I will read more of it later. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/2/12 9:53 AM, Doug Barton wrote: On 08/02/2012 09:44, Garrett Cooper wrote: The Watson/Losh connection worked really well in BSDCan 2010 :). I wasn't going to mention that, since I didn't want to tell tales out of school. But the fact that remote participation actually was provided for the right people, even though I was told repeatedly that it wasn't possible, actually highlights a big part of the problem. bandwidth was limited and a single 1:1 skype connection was all we really could do. I did broadcast sessions a few years ago using the apple quicktime server but it was a lot of work and I think one person looked at part of one session. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/12 12:45 PM, Arnaud Lacombe wrote: Hi, On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao atti...@freebsd.org wrote: As for the mbuf meeting, all I can find from it online is: http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html actually nothing has happenned on this yet that I know of, which is why there has been no action to see. We all agree that it is an item to put on our agenda but until there is someone who gets the free time it's just a sanctioned priority item which is not worth much... Rather than doing things internally, maybe it is time to open up... oh, wait, you will certainly come to the community with a design plan, figure out it's not gonna work while doing the implementation, change the design plan while implementing, go public with a +3k/-2k loc change patch, ask for benediction, go ahead and commit it up until someone comes with an obvious design flaw which would render the change pretty much useless, but there will be man-month of work to fix it, so it's never gonna be done. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to diagnose system freezes?
On 7/31/12 5:02 PM, Yuri wrote: One of my 9.1-BETA1 systems periodically freezes. If sound was playing, it would usually cycle with a very short period. And system stops being sensitive to keyboard/mouse. Also ping of this system doesn't get a response. I would normally think that this is the faulty memory. But memory was recently replaced and tested with memtest+ for hours both before and after freezes and it passes all tests. One out of the ordinary thing that is running on this system is nvidia driver. But the freezes happen even when there is no graphics activity. Another out of the ordinary thing is that the kernel is built for DTrace. But DTrace was never used in the sessions that had a freeze. What is the way to diagnose this problem? The answer depends on a number of things but an NMI can be useful if you have some way of generating them. (some IPMI implementations can allw you to generate them and some motherboards have jumpers to allow you to attach a 'nmi-button'. The fact that ping is not responsive is important, as that is done at a very low level but it may still be alive down there somewhere. Make sure you have debugging enabled in your kernel. That will catch quite a few 'hangs'. as also mentioned by others... a serial console and DDB may also be useful in some hangs. Julian CPU: i7 CPU 920 @ 2.67GHz Memory: 24GB MB: P2T Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: proper newfs options for SSD disk
On 5/24/12 5:35 AM, Warren Block wrote: On Wed, 23 May 2012, Tim Kientzle wrote: On May 22, 2012, at 7:40 AM, Warren Block wrote: On Tue, 22 May 2012, Matthias Apitz wrote: El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió: On Tue, 22 May 2012, Matthias Apitz wrote: El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com escribió: Do not use MBR (or manually do all to align). 63 - not 4k aligned. To create the above shown partition layout I have not used gpart(8); I just said: # fdisk -I /dev/ada0 # fdisk -B /dev/ada0 ... What is wrong with this procedure? The filesystem partitions end up at locations that aren't even multiples of 4K. This can reduce performance. How much probably depends on the SSD. But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) A bug in the design of MBR. Which probably can be forgiven, considering when it was created and the other problems with it. :) gpart's alignment option can be used with MBR slices and bsdlabel partitions. GPart's alignment option doesn't work for MBR slices. It rounds to the requested alignment, and then rounds again to the track size, which defaults to 63 sectors. There's an example in my proposed rewrite of the Handbook RAID1 section: http://www.wonkity.com/~wblock/mirror/book.html The slice starts at block 126, two blocks shy of 4K alignment. With the added two blocks for the bsdlabel, all of the FreeBSD partitions end up aligned at even 4K multiples. A filesystem in the raw slice would be misaligned. Presumably the answer is well don't do that, then (always use a bsdlabel with MBR), or some trick to skip a couple of blocks like gnop. If there are any mistakes in that example, please help me correct them to avert steps 4 and 5 of the traditional commit process (4: apologize, and 5: fix and recommit). I'm not convinced this is a bug in the design of MBR. I don't think anything in the MBR design requires that partitions be track-aligned. I meant bug in the sense of a missing feature. MBR may not have a provision for fixed alignment, but to its credit, doesn't prevent it either. WYYY back when disk drives and BIOS cared about this the size of a track was signalled past various scope barriers to the actual driver by setting the sectors per-track and heads-per-drive to the maximum values for that actual drive.. i.e. we assumed that the partition ENDED on a cylinder boundary and used that to extrapolate the actual geometry, which the driver actually needed to be able to drive the driver correctly. (a block number had to be divided into cyls and heads to get teh right place to go to.) none of that is true any more on any drive we care about and even if it was we can now read bios tables. so we can stick the damned partitions where ever we want, and Even the BIOS can find them (since mid 90's).. yeah I wrote it.. about time to remove it.. take that 63/255 out and shoot it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [jail] Allowing root privledged users to renice
On 5/25/12 10:04 AM, Bjoern A. Zeeb wrote: On 25. May 2012, at 16:48 , Sean Bruno wrote: I've been toying with the idea of letting jails renice processes ... how dangerous and/or stupid is this idea? //depot/yahoo/ybsd_9/src/sys/kern/kern_jail.c#5 - /home/seanbru/ybsd_9/src/sys/kern/kern_jail.c 270a271,275 + int jail_allow_renice = 0; + SYSCTL_INT(_security_jail, OID_AUTO, allow_renice, CTLFLAG_RW, +jail_allow_renice, 0, +Prison root can renice processes); 3857a3863,3865 + case PRIV_SCHED_SETPRIORITY: + if (!jail_allow_renice) + return (EPERM); I think sysctls are a bad idea given jails have per-jail flags these days. Maybe also only allow re-nicing to be nicer but not less nice? for sure ! start a jail with it's max priority and the root within can allow nicer priorities only.. you can always add priority from teh master (parent) environment outside. /bz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: PID/UID namespaces
On 5/21/12 6:47 AM, David Windsor wrote: Hi, While doing some research on FreeBSD jails, I came across an item in the jails' TODO: - be able to have a separate PID space for it - be able to specify a separate UID space for it In other projects, these goals have been accomplished using namespaces. I tried to see if PID/UID namespaces existed in BSD and came across something called Capsicum, a sandboxing project which does not appear to implement outright namespaces for descriptors like PID/UID, but uses something called a Process Descriptor. Is namespacing of PIDs and UIDs an eventual goal of the jails project of FreeBSD? kinda Note terribly explicitly, but somewhere in our collective subconscious.. Thanks, David PS: Excuse my ignorance of anything related to BSD, as I come from a Linux background. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is there any modern alternative to pstack?
On 4/4/12 5:44 AM, Eitan Adler wrote: On 4 April 2012 01:41, Julian Elischerjul...@freebsd.org wrote: should be in ports? Not unless someone decides to become the new upstream and make a release. We do not maintain software in ports. but we do add patches to make things work on FreeBSD. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is there any modern alternative to pstack?
On 4/2/12 10:12 AM, John Baldwin wrote: On Monday, April 02, 2012 12:39:26 pm Yuri wrote: On 04/02/2012 05:31, John Baldwin wrote: Hmm, I don't know if the port has it, but I did some work on pstack a while ago to make it work with libthread_db so it at least handles i386 ok. It needs to be modified to use something like libunwind though or some other unwinder. And possibly it should use libelf instead of its own ELF-parsing code. I see pstack -1.2_1 failing even on i386: pstack: cannot read context for thread 0x1879f pstack: failed to read more threads Yes, threads don't work for modern binaries (newer than 4.x) without my changes to make it use libthread_db. You can find the patch I used for this at http://www.freebsd.org/~jhb/patches/pstack_threads.patch should be in ports? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Capture states of all processes at the same time
On 3/14/12 12:02 PM, Artem Belevich wrote: On Wed, Mar 14, 2012 at 11:25 AM, Maninya Mmani...@gmail.com wrote: Then typed this to force a panic: sysctl debug.kdb.panic=1 The computer just hung after this, and after waiting for a while I pressed the reboot button. It said no core dumps found while rebooting. First, make sure you have swap space configured. If minidump is not enabled (check sysctl debug.minidump) you will need to make sure you have more swap space than physical memory. Then make sure that dump device is set up correctly. See dumpdev in rc.conf(5) If that didn't work, you may be running into the issue in PR kern/155421: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F155421cat= Alas, I don't know what to do about that. or just do ps from ddb and then continue. you can set things up in 9 (and maybe 8, I don't know) to capture the ddb output.. --Artem ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
will 9.2 be called 'diehard'? or maybe Naktomi?
http://modcult.org/read/2008/2/20/nakatomi-socrates-bsd-9-2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Never forget a special trick...
On 3/4/12 12:47 PM, Devin Teske wrote: On Mar 4, 2012, at 12:29 PM, Phillip Spring wrote: Dear anonymous open-source enthusiasts friends, How to echo a string backwards into a terminal? For example (or something like this): # echo @_foo_$ oof Or it could be something else (that's because I forgot it): # echo $_bar_@ rab Someone told me how to do it but I can't remember this trick. I just remember the date it happened: Oct-13-2011 You're looking for rev(1) Example: # echo foo | rev oof gosh, how did I survive so long without this program..? oh yeah.. I remember.. never needed to do that.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
o
On 2/26/12 5:34 AM, Bob Bishop wrote: Hi, I'd like to hear from somebody who understands this stuff on the relative merits of blackhole routes vs firewall drop rules for dealing with packets from unwanted sources. I'm particularly interested in efficiency and scalability. Thanks the key is the word from. routes can only be selected on 'TO' (destination) where firewalls can select on any combination of header fields. -- Bob Bishop r...@gid.co.uk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Blackhole routes vs firewall drop rules
let's try that again with the right Subject: line On 2/26/12 1:05 PM, Julian Elischer wrote: On 2/26/12 5:34 AM, Bob Bishop wrote: Hi, I'd like to hear from somebody who understands this stuff on the relative merits of blackhole routes vs firewall drop rules for dealing with packets from unwanted sources. I'm particularly interested in efficiency and scalability. Thanks the key is the word from. routes can only be selected on 'TO' (destination) where firewalls can select on any combination of header fields. -- Bob Bishop r...@gid.co.uk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: o
On 2/26/12 1:14 PM, Matthias Apitz wrote: El día Sunday, February 26, 2012 a las 01:05:11PM -0800, Julian Elischer escribió: On 2/26/12 5:34 AM, Bob Bishop wrote: Hi, I'd like to hear from somebody who understands this stuff on the relative merits of blackhole routes vs firewall drop rules for dealing with packets from unwanted sources. I'm particularly interested in efficiency and scalability. Thanks the key is the word from. routes can only be selected on 'TO' (destination) where firewalls can select on any combination of header fields. I understand the idea of the OP as, based on the source IP addr, he wants to install routes that the resulting IP pkg to the source IP goes to nowhere, i.e. not back to the origin IP and the 1st SYN is not answered back to the source IP; yes but that is wasteful because you have used resources answering the incoming packet. it would be better to have blocked it in the first place. matthias ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: OS support for fault tolerance
On 2/20/12 6:32 AM, Da Rock wrote: On 02/15/12 03:25, Brandon Falk wrote: On 2/14/2012 12:05 PM, Jason Hellenthal wrote: On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote: On 2/14/12 6:23 AM, Maninya M wrote: For multicore desktop computers, suppose one of the cores fails, the FreeBSD OS crashes. My question is about how I can make the OS tolerate this hardware fault. The strategy is to checkpoint the state of each core at specific intervals of time in main memory. Once a core fails, its previous state is retrieved from the main memory, and the processes that were running on it are rescheduled on the remaining cores. I read that the OS tolerates faults in large servers. I need to make it do this for a Desktop OS. I assume I would have to change the scheduler program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. How do I go about doing this? What exactly do I need to save for the state of the core? What else do I need to know? I have absolutely no experience with kernel programming or with FreeBSD. Any pointers to good sources about modifying the source-code of FreeBSD would be greatly appreciated. This question has always intrigued me, because I'm always amazed that people actually try. From my viewpoint, There's really not much you can do if the core that is currently holding the scheduler lock fails. And what do you mean by 'fails? do you run constant diagnostics? how do you tell when it is failed? It'd be hard to detect that 'multiply' has suddenly started giving bad results now and then. if it just stops then you might be able to have a watchdog that notices, but what do you do when it was half way through rearranging a list of items? First, you have to find out that it held the lock for the module and then you have to find out what it had done and clean up the mess. This requires rewriting many many parts of the kernel to remove 'transient inconsistent states. and even then, what do you do if it was half way through manipulating some hardware.. and when you've figured that all out, how do you cope with the mess it made because it was dying? Say for example it had started calculating bad memory offsets before writing out some stuff and written data out over random memory? but I'm interested in any answers people may have How about core redundancy ? effectively this would reduce the amount of available cores in half in you spread a process to run on two cores at the same time but with an option to adjust this per process etc... I don't see it as unfeasable. The overhead for all of the error checking and redundancy makes this idea pretty impractical. You'd have to have 2 cores to do the exact same thing, then some 'master' core that makes sure they're doing the right stuff, and if you really want to think about it... what if the core monitoring the cores fails... there's a threshold of when redundancy gets pointless. Make no mistake here, I'm not really up with the guts of what this would require (the dog may not hunt at all). Consider me as the little boy throwing rocks at a hornets nest :) That out of the way, how about this scenario: why can't the master be dynamic amongst the cores? 1 core be the master of any 2 cores (not itself). Another thought (probably more scifi then anything else) is about using the cores as individuals which work as a team and fire a weak team member that is failing. I have absolutely no idea how to accomplish this, but I thought it might fire a few neurons in someone who does... :) There are so many reasons this would be ineffective on standard hardware I have no idea where to begin, but see my email above.. Perhaps I'm missing out on something, but you can't check the checker (without infinite redundancy). Honestly, if you're worried about a core failing, please take your server cluster out of the 1000 deg C forge. -Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: 8 to 9: Kernel modularization -- did it change?
On 02/17/12 14:08, rank1see...@gmail.com wrote: For me as a user, that would be a much preferable approach, instilled long ago by Linux. I don't like unused stuff around, and I like to understand what I am using. Some build kernel confutation parameters minimum modules, medium modules, maximum modules might be utilized. I would be using medium or most likely maximum, leaving me with a minimal kernel. -- Alex -- alex-goncha...@comcast.net -- NO. Thinking bigger picture (beyond sound), would it make sense to keep GENERIC very minimal, but provide an extensive loader.conf with a default install...so most things worked, but were loaded as modules? Matt NO. You can't base a wish on a solution for YOURS problems! GENERIC must be as giantic as possible, to make as many machines as possible to BOOT and enable all what can be enabled in/on them. THEN ... individual strips unhooked parts - custom kernel, via wich you specialize it, for your hardware! That is, unless individual is passive/bored (lazy?) and prefer everything on a silver plate ... There are many paths in that case ... Windows are the easiest solution. THEY THINK FOR YOU! ;) Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org I'm tired of Linux and everything should be in the kernel, implemented 4 ways approach. I think you misunderstood. GENERIC should be able to boot anything bootable within the architecture, right? We agree on that. Is sound required for booting? We have a modular kernel. It makes best-practices-sense to keep the kernel true to what's required to boot and initialize the hardware required to come up multiuser. I am actually against having sound in there at all. However, as a compromise, if it must be in there, then put it in loader.conf and not the kernel. Do we still disagree? I think we probably should go two ways long and short term 1/ generic is installed at boot a) also install a truely minimal kernel and configure modules to use with it. but only once up and running with GENERIC. 2/ in the logn term we should add teh ability to detect devices and load modules needed.. either from the loader, or in early boot. Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: OS support for fault tolerance
On 2/14/12 6:23 AM, Maninya M wrote: For multicore desktop computers, suppose one of the cores fails, the FreeBSD OS crashes. My question is about how I can make the OS tolerate this hardware fault. The strategy is to checkpoint the state of each core at specific intervals of time in main memory. Once a core fails, its previous state is retrieved from the main memory, and the processes that were running on it are rescheduled on the remaining cores. I read that the OS tolerates faults in large servers. I need to make it do this for a Desktop OS. I assume I would have to change the scheduler program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. How do I go about doing this? What exactly do I need to save for the state of the core? What else do I need to know? I have absolutely no experience with kernel programming or with FreeBSD. Any pointers to good sources about modifying the source-code of FreeBSD would be greatly appreciated. This question has always intrigued me, because I'm always amazed that people actually try. From my viewpoint, There's really not much you can do if the core that is currently holding the scheduler lock fails. And what do you mean by 'fails? do you run constant diagnostics? how do you tell when it is failed? It'd be hard to detect that 'multiply' has suddenly started giving bad results now and then. if it just stops then you might be able to have a watchdog that notices, but what do you do when it was half way through rearranging a list of items? First, you have to find out that it held the lock for the module and then you have to find out what it had done and clean up the mess. This requires rewriting many many parts of the kernel to remove 'transient inconsistent states. and even then, what do you do if it was half way through manipulating some hardware.. and when you've figured that all out, how do you cope with the mess it made because it was dying? Say for example it had started calculating bad memory offsets before writing out some stuff and written data out over random memory? but I'm interested in any answers people may have ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: OS support for fault tolerance
On 2/14/12 9:27 AM, Rayson Ho wrote: On Tue, Feb 14, 2012 at 11:57 AM, Julian Elischerjul...@freebsd.org wrote: but I'm interested in any answers people may have The way other OSes handle this is by detecting any abnormal amounts of faults (sometimes it's not the fault of the hardware - eg. when a partical from the outerspace hits a core and flips the bit), then the disable the core(s). Solaris mainframe (z/OS) handle it this way, but you should google and find more info since I don't remember all the details. Also, see this presentation: Getting to know the Solaris Fault Management Architecture (FMA): http://www.prefetch.net/presentations/SolarisFaultManagement_Presentation.pdf True, but you can't guarantee that a cpu is going to fail in a way that you can detect like that. what if the clock just stops.. I believe that even those systems that support cpu deactivation on error only catch some percentage of the problems, and that sometimes it was more of bring up the system without cpu X after it all crashed in flames. tandem and other systems in the old day s used to be able to cope with dying cpus pretty well but they had support from to to bottom and the software was written with 'clustering' in mind. Rayson = Open Grid Scheduler / Grid Engine http://gridscheduler.sourceforge.net/ Scalable Grid Engine Support Program http://www.scalablelogic.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: OS support for fault tolerance
On 2/14/12 3:51 PM, Jan Mikkelsen wrote: Coming back to the multicore issue: The problem when a core fails is that it has affected more than its own state. It will be holding locks on shared resources and may have corrupted shared memory or asked a device to do the wrong thing. By the time you detect a fault in a core, it is too late. Checkpointing to main memory means that you need to be able to roll back to a checkpoint, and replay operations you know about. That involves more that CPU core state, that includes process file and device state. I think that/s more or less what I was saying but with more concrete examples. and yes I rememebr the tandem boxes from computer shows in Perth and Sydney, but never saw one in the field. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] multiple instances of ipfw(4)
On 2/8/12 6:09 AM, Gleb Smirnoff wrote: On Wed, Feb 08, 2012 at 03:04:09PM +0100, Ermal Lu?i wrote: E 2012/2/8 Gleb Smirnoffgleb...@freebsd.org: EOn Tue, Jan 31, 2012 at 12:02:04PM +0100, Luigi Rizzo wrote: EL if i understand what the patch does, i think it makes sense to be EL able to hook ipfw instances to specific interfaces/sets of interfaces, EL as it permits the writing of more readable rulesets. Right now the EL workaround is start the ruleset with skipto rules matching on EL interface names, and then use some discipline in reserving a range EL of rule numbers to each interface. E EThis is definitely a desired feature, but it should be implemented Eon level of pfil(9). However, that would still require multiple Einstances of ipfw(4). E E This opens a discussion of architecture design. E I do not think presently pfil(9) is designed to handle such thing! Several years ago, I guess around 2005, a discussion on a per-interface packet filtering was taken on the net@ mailing list. In that time, it lead to nothing, several people were against the idea. Recently on IRC I had raised the discussion again. Today more people liked the idea and found it a desired feature. Many kinds of high end networking equipment have per-interface ACLs. I know that networking sysadmins would be happy if FreeBSD packet filters would get this feature, since maintaing such ACLs is much easier on a router with dozens of interfaces. I think it is a good idea. not only for interfaces but certain routing and bridging paths too. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFT][patch] Scheduling for HTT and not only
On 2/6/12 11:10 AM, Alexander Best wrote: On Mon Feb 6 12, Alexander Motin wrote: On 02/06/12 19:37, Tijl Coosemans wrote: On Monday 06 February 2012 17:29:14 Alexander Motin wrote: On 02/06/12 18:01, Alexander Best wrote: On Mon Feb 6 12, Alexander Motin wrote: I've analyzed scheduler behavior and think found the problem with HTT. SCHED_ULE knows about HTT and when doing load balancing once a second, it does right things. Unluckily, if some other thread gets in the way, process can be easily pushed out to another CPU, where it will stay for another second because of CPU affinity, possibly sharing physical core with something else without need. I've made a patch, reworking SCHED_ULE affinity code, to fix that: http://people.freebsd.org/~mav/sched.htt.patch This patch does three things: - Disables strict affinity optimization when HTT detected to let more sophisticated code to take into account load of other logical core(s). - Adds affinity support to the sched_lowest() function to prefer specified (last used) CPU (and CPU groups it belongs to) in case of equal load. Previous code always selected first valid CPU of evens. It caused threads migration to lower CPUs without need. - If current CPU group has no CPU where the process with its priority can run now, sequentially check parent CPU groups before doing global search. That should improve affinity for the next cache levels. Who wants to do independent testing to verify my results or do some more interesting benchmarks? :) i don't have any benchmarks to offer, but i'm seeing a massive increase in responsiveness with your patch. with an unpatched kernel, opening xterm while unrar'ing some huge archive could take up to 3 minutes!!! with your patch the time it takes for xterm to start is never10 seconds!!! Thank you for the report. I can suggest explanation for this. Original code does only one pass looking for CPU where the thread can run immediately. That pass limited to the first level of CPU topology (for HTT systems it is one physical core). If it sees no good candidate, it just looks for the CPU with minimal load, ignoring thread priority. I suppose that may lead to priority violation, scheduling thread to CPU where higher-priority thread is running, where it may wait for a very long time, while there is some other CPU with minimal priority thread. My patch does more searches, that allows to handle priorities better. But why would unrar have a higher priority? I am not good with ULE priority calculations yet, but I think there could be many factors. Both GUI and unrar probably running with the same nice level of 0, so initially they are equal. After they started, their priorities depend on spent CPU time, calculated interactivity and who knows what else. So possibly at some moments unrar may get priority higher then GUI. Also there can participate several kernel threads, that have higher priority by definition. one factor might also be that by doing i/o, a process can gather a higher priority compared to a task that's doing cpu intensive stuff. statistics have shown (at least historically) that i/o intensive tasks tend to trigger i/o bursts and then either quit or stay idle. so schedulers usually prefer those processes, since there's quite a big chance their request can be delivered in one time slice. cpu intensive tasks on the other hand usually require more than one time slice. this might cause a situation, where the 'unrar'-process is being handled at a very high priority in order to finish its i/o burst. however since unrar'ing a big file isn't really an i/o burst, the cpu intensive process (or any other process in general) will suffer from starvation. this is just a wild guess though. it might be complete nonsense, since i haven't got a clue what kind of scheduling (rr, fcfs, ...) ULE is doing. btw: does anybody know, if there are plans to commit the BFS scheduler to HEAD at some point? personally i think what be even better than a new schuduling algorithm would be a scheduling infrastructure similar to GEOM. that way it would be much easier to implement new algorithms (maybe in XML). a scheduler 'framework' is rather hard to do because the scheduler interface is complicated.. I and others did try abstract teh scheduler a bit in about 2000. As you can see we did manage to have 2 separate schedulers.. adding a third should be easier but the current interface is still slightly tied to the things that those two schedulers need. cheers. alex -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A dual-ISP hack with jail/vnet and ipfw
On 2/4/12 9:05 AM, Poul-Henning Kamp wrote: Natd(8) knows how to deal with multiple NAT instances for different interfaces, which is useful when you have multiple ISPs. The problem with it, is that it becomes incredibly hairy to configure your IPFW rules, in particular if you have other policy to implement too. this is sort of what I did when I switched ISPs recently, and had a transition period.. I had a jail/vnet for each ISP. and just switched at the top level an unexpected advantage was that sessions from the main machine were 'one hop' away from the disruption when I screwed things so instead of getting terminated when teh rules/routes were screwed, they just 'hung' until I fixed things. Much like they do when there is internet disruption between sites. I've meant to do something cleaner like this for a while.. good move. I spent some quality time with a 9.0-Stable nanobsd image today, and the script below is my proof of concept of a simpler way to do that. The idea is to let a jail deal with the two ISPs and use an epair to deliver a normal default route interface to the rest of the firewall, making its configuration simpler and easier to understand. [...] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] multiple instances of ipfw(4)
On 1/31/12 12:53 AM, Ermal Luçi wrote: On Mon, Jan 30, 2012 at 10:08 PM, Vadim Goncharov vadim_nucli...@mail.ru wrote: Hi Ermal Lu?i! On Mon, 30 Jan 2012 13:01:13 +0100; Ermal Lu?i wrote about '[PATCH] multiple instances of ipfw(4)': from needs on pfSense a patch for allowing multiple intances of ipfw(4) in kernel to co-exist was developed. It can be found here https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff Hmm, looking at the lines if (oif !(oif-if_flags IFF_IPFW_FILTER)) return (IP_FW_PASS); it appears that a patch is made against somewhat private, I couldn't find that in stock FreeBSD. Yeah its not so polished patch, and the remaining parts are still there in the same repo. Though its redundant to this patch. It is used in conjuction with this tool https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c It allows creation of contextes/instances and assignment of specific interfaces to specific contexts/instances. It is not clear how to add a rule to a specific instance with this program. Simple example: - Create a context with members ipfw_context -a testctx ipfw_context -a testctx -n myiface0 ipfw_context -a testctx -n myiface1 - Set the context ipfw_context -s testctx - Continue business as usual with ipfw/dummynet ipfw add ipfw pipe create ipfw table add Surely i know that this is not the best way to implement generically but it gets the job done for us as it is, read below. What i would like to know is if there is interest to see such functionality in FreeBSD? I am asking first to see if there is some consensus about this as a feature, needed or not! If interest is shown i will transform the patch to allow: - ipfw(8) to manage the contextes create/destroy - ipfw(8) to manage interface membership. Closing the race of two parallell clients modifying different contextes. There is another design choice to be made about storing the membership of interfaces into contexts/instances, but i do not see that as blocking. It is quite handy feature, which can be exploited even to scale on SMP machines by extending it to bind a specific instance(with its interaces) to a specific CPU/core?! Not so simple/straightforward questions. On the one hand, there are at least /some/ people who need this. So the ipfw 'call'/'return' actions were already implemented, first appearing in 9.0-R / 8.3-R. And melifaro@ has patches to ipfw table allowing matching againt ifname, setting tablearg, which in conjunction with 'call' or 'skipto' could be used to make essentially the same functionality as your proposed patch, already in stock FreeBSD. Well it tends to get messy if you do not have a smart consumer handling the jumps. Its almost as reprogramming in ipfw language and somehow an admin needs to read this! The intention was be practical and allow easy troubleshooting. On the other hand, both ipfw contexts and ipfw 'call' are very half-measures. The only goal was to give people something right now, and see how much this will be demanded, what feedback they'll give, etc. It is obvious there is no wide testing of 9.0-R (and 8.3-R too) right now. It depends on the needs, surely and how colorful you want it to be. What I mean here about half-measures? The ipfw 'call' is just a sketch of my old ideas to completely reorganize ipfw to support multiple rulesets. To be generic and Right Thing(tm), this is a HUGE work, because: - each ipfw chain becomes independent netgraph(4) node what about the existing netgraph ipfw node someone wrote a few years ago? I saw it but don't know if it was sent out publicly. - generic ng_pfil node usable not only for firewalls - chains may be called from each other (see iptables) - chains (actually netgraph nodes) may be bind to ifaces or any other place - main unnamed chain is called from pfil as before - rewrite ipfw dummynet management from setsockopt() to netgraph messages - completely rewrite ipfw dynamic rules to not conflict with multiple rulesets, as now they just jump to parent static rule (need to be more like pf or iptables states). This item is hard but essential (you'll get a mess jumping to another ruleset), and ipfw contexts don't handle ot - while here, do other needed things, e.g. adding support for modules in both kernel and userland, loadable opcodes, keywords, etc. if you write a ip/tcp/udp/... stack on netgraph than i will write this :) Though its a matter of preference and how much work its needed to accomplish this! Surely ipfw has seen a lot of hacks in the past and will see in the future but i thik usability is more of a target rather than fancy design. But surely nothing should stop both ways. Even if not add something like bpf, that's ipfw_ng is probably a more major change than both ipfw2 and ipfw3 :) Due to various reasons in my private life, I was unable to do it in my spare time previous
Re: [PATCH] multiple instances of ipfw(4)
On 1/30/12 4:01 AM, Ermal Luçi wrote: Hello, from needs on pfSense a patch for allowing multiple intances of ipfw(4) in kernel to co-exist was developed. It can be found here https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff It is used in conjuction with this tool https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c It allows creation of contextes/instances and assignment of specific interfaces to specific contexts/instances. Surely i know that this is not the best way to implement generically but it gets the job done for us as it is, read below. What i would like to know is if there is interest to see such functionality in FreeBSD? I am asking first to see if there is some consensus about this as a feature, needed or not! If interest is shown i will transform the patch to allow: - ipfw(8) to manage the contextes create/destroy - ipfw(8) to manage interface membership. Closing the race of two parallell clients modifying different contextes. There is another design choice to be made about storing the membership of interfaces into contexts/instances, but i do not see that as blocking. It is quite handy feature, which can be exploited even to scale on SMP machines by extending it to bind a specific instance(with its interaces) to a specific CPU/core?! for this I use multiple vimages, but just as there is room for multiplt routing tables AND vimage, there is probably room for multiple firewalls AND vimage. this is a bit more in the iptables direction I guess. Comments/Feedback expected, Ermal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kqueue and note_rename
On 1/25/12 10:44 AM, Matthias Zitzen wrote: Hello list, does anybody have an idea, how to obtain the new name of a renamed file after the note_rename event is fired. I'm not very familiar with filesystem-operations. I checked the typical functions like stat or lstat, but these functions are working only with filenames. there is no real way. the new link to the inode could come from any point in the filesystem so the only way to find it would be an exhaustive search. the only information that you could return that might make any sense would be the inode number of the new parent. That would allow you to follow the '..' links and do 'pwd' in effect. I have not checked to see if that information is returned. If it isn't it might be a really nice enhancement to see if it could be added. Matthias ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Rebooting/Halting system from kernel module
On 1/22/12 2:19 AM, geoffrey levand wrote: Hi, how would i reboot/halt the system from a kernel module ? the answer is that depends.. do you want to sync the disks first? of just hard reset? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/18/12 3:32 AM, Robert Watson wrote:
Another possibility is to get some combination of {The FreeBSD
Foundation, iX Systems, ...} to trawl the bug report database in a
more official capacity. The problem there is that this will be a
high burn-out job. I'll bring it up at the next Foundation board
meeting, especially after a bumper year of fund-raising, and see
what we can do.
we really need a bud-submitting-user advocate..
Someone (need not have a commit bit) who doesn't take charge of the
patch, but, rather,
acts as a project manager in hte process of getting it in.
i.e. finding, and then pinging the approriate developer, and
occasionally nagging them or
finding an alternate dev if the first choice is unresponsive.
diplomatic skill would be important.. maybe a woman might be best in
this job as the developers tend to not want to be rude to women :-) .
Robert
___
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/16/12 10:20 PM, John Kozubik wrote: On Tue, 17 Jan 2012, Steven Hartland wrote: I was disappointed to see that 8.3-RELEASE is now slated to come out in March of 2012. This will be ~13 months since 8.2-RELEASE and is typical of a trend towards longer gaps between minor releases. ... I must say as a small company that runs ~200 machines on FreeBSD I do see where John is coming from, as it is very time consuming to keep things up to date and new is not always better e.g. we still have boxes stuck on 6.x as issues introduced in the Linux compat after that caused problems. That said I'm in two minds as the features that have been brought in by the more rapid dev cycle like ZFS have been great. The features are great - nobody doesn't want the features! Like I said in the original post, as wonderful as ZFS on FreeBSD is (and we are deploying it this year) it is only now (well, in March) with 8.3 that I feel it is finally safe and stable enough to bet the farm on. I'm not the only one that feels this way. If that's the case, then, ZFS could have been developed just as it has, in a development branch, and not been used as justification for (mutiple) major releases and all of their disruption. but it would not have gotten the testing it did. As I said in the original post - we should be on 6.12 right now, and bringing out 7.0, with ZFS v28. that was my feeling when we went to this bring out a new major release every 3 weeks scheme. We must however look at why Major and Minor releases are different. A major release means that kernel ABIs (inside the system) have changed. We needed to change the ABIs between 4 and 5 for sure (threaded kernel) and between 6 and 7 for sure, (second round of threading work). 7 and 8 also really required a change. I'm not sure about 5-6 and 8-9. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/16/12 10:29 PM, Atom Smasher wrote: so i guess that means that i'm tougher than a typical laptop user... and instead of making things easier, freeBSD is getting harder. thing is, when people don't play with freeBSD on laptops and desktops, then they grow up, get real jobs, and don't know much about it. if this keeps up, i'll cross a line where i just get more comfortable with linux and migrate my freeBSD servers to it. this is one of the areas where linux is doing well... people are playing with it, but in the process they're getting used to it and comfortable with it. from that background, they can install a linux based server without breaking a sweat. linux's ease of use and hardware support are seeding the next generation of FLOSS and *nix users... and most of them have never installed/used freeBSD. have a play with PCBSD some time ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 10:08 AM, John Kozubik wrote: Hi Ivan, [...] Fair enough. Is it the case that if funds or manpower were made available, more releases would be workable ? Or are there some deeper cultural leanings toward having fewer minor releases ? sure if you or someone is willing to cut releases, you can do so and I'm sure re@, given the resources (not just promised them) could do things differently. re would probably love to have people employed by someone to do the job :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 7:39 AM, Mark Felder wrote: Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. I'm going to go both ways on this one. Where I used to work (Devin Teske is now there) we used to use the 'stable' branch and rolll our own releases. the criticality of those systems was hard to over-emphasize. In 2005 we worked out we processed 1.5 trillion dollars of transactions on those systems. The other side of the coin is that we had the resources to have someone (me) tracking the branch. I only spun a release when I thought it was a good time to do so, but I always had a year or so advance warning of when a new release was likely to be needed so I could select a good moment from over a wide range. Also ran a layer on the top of the sources where I could add cherry-picked back-ports and changes as part of our release. If it came to that maybe all the people who are currently saying they need better support of the 8.x branch could get together and together, support someone to do that job for them..would 1/5th of a person be too expensive for them? if not, what is a reasonable cost? Is it worth 1/20 th of a person? Julian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 9:36 AM, Damien Fleuriot wrote: On 1/17/12 4:39 PM, Mark Felder wrote: Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. Running FBSD in a *production* environment means you want something stable and tested. -STABLE does not fulfill the requirements I'm afraid. We've had to downgrade some boxes from 8.2-STABLE to -RELEASE here. then you went the wrong way and your process is flawed. having run -stable on production systems, the way to do it is: * follow -stable.. * pick a time that IN RETROSPECT (from 1 month later) looks as though it was good. * take a snapshot from that time and test it. * if it has problems MOVE FORWARD (not back) to the next candidate snapshot time. * repeat until you have one that works for you ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 12:11 PM, Mark Saad wrote: Here are My 2 Cents , 1. Support each release longer, or develop a better way to MFS ( Merge from Stable ) bug fixes, and driver updates to RELEASE. It always seams that there are a number of things in X-STABLE I would love to have in X.3-RELEASE and X.4-RELEASE, and I do not want all of X-STABLE just some new drivers and fixes . 2. Spell out the entire RELEASE road map at the beginning of the release. So for 9.0-RELEASE set tentative dates for 9.1, 9.2, 9.x etc . I think by the .2 release of a line we should have some idea as to whether a particular lineage is going to provide a good basis for extended life. if for example we were to declare that 8 is really quite good, we might decide to declare it as having a longer life and allow 9 to die earlier as we go forward. I do understand the requirement for a stable basis for work but I can not say how many of the changes for newer hardware will get ported back. or by who. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 3:36 PM, Ian Lepore wrote: On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote: on 17/01/2012 23:46 Ian Lepore said the following: Now, before we're even really completely up and running on 8.2 at work, 9.0 hits the street, and developers have moved on to working in the 10.0 world. What are the chances that any of the patches I've submitted for bugs we fixed in 8.x are ever going to get commited now that 8 is well on its way to becoming ancient history in developers' minds? My opinion is that this will have more to do with your approach to pushing the patches (and your persistence) rather than with anything else. As long as stable/8 is still a supported branch or the bugs are reproducible in any of the supported branches. Well I submitted a sort of random sample of the patches we're maintaining at work, 11 of them as formal PRs and 2 posted to the lists here recently. So far two have been committed (the most important one and the most trivial one, oddly enough). I'm not sure just how pushy one is supposed to be, I don't want to be a jerk. Not to mention that I wouldn't know who to push. That's actually why I'm now being active on the mailing lists, I figured maybe patches will be more accepted from someone the commiters know rather than just as code out of the blue attached to a PR. you are supposed to be as pushy as you need to be.. If you really want your patches in I'd suggest teh following method: 1/ post a summary email explaining all teh bugs and patches 2/ see if anyone takes them up 3/ for the remaining problems, find the names of developers who have committed to that code and contact them asking for their assistance. 4/ report back here ;-) I think it would be great if there were some developers (a team, maybe something not quite that formal) who concentrated on maintenance of older code for the user base who needs it. I'd be happy to contribute to that effort, both on my own time, and I have a commitment from management at work to allow me a certain amount of billable work hours to interface with the FreeBSD community, especially in terms of getting our work contributed back to the project (both to help the project, and to help us upgrade more easily in the future). I have no idea if there are enough developers who'd be interested in such a concept to make it work, co-op or otherwise. But I like the fact that users and developers are talking about their various needs and concerns without any degeneration into flame wars. It's cool that most of the focus here is centered on how to make things better for everyone. -- Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 2:41 PM, Matthew D. Fuller wrote: On Tue, Jan 17, 2012 at 06:57:19PM + I heard the voice of Hugo Silva, and lo! it spake thus: Come to think about it, those days are pretty much gone since 4.x (incidentally, many of us who've stuck with FreeBSD for this long think of 4.x as an epic series). Having been a FreeBSD user for a very long time, I don't think of 4.x as epic. I think of 5.x as a clusterf...un. 4.x didn't last such a long time because everyone thought it was awesome, it was because the next version was still so broken it was the only thing we had to release. 5 was not out on a limb for so long because it was a clusterfun, it was out there because it was a rework of how almost everything in the kernel worked. Everything written since 1978 had to be rewritten to some extent. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 3:50 PM, Doug Barton wrote: First, let's do away with the whole, If you step up to help, your help will be accepted with open arms myth. That's only true if the project leadership agrees with your goals. leadership doesn't really control development here. action does. We also need to take a step back and ask if throwing more person-hours at the problem is the right solution, or if redesigning the system to better meet the needs of the users *as a first step* is the right answer? careful, you are starting to sound reasonable there.. On 01/17/2012 15:01, Adrian Chadd wrote: .. I'm replying to the OP because honestly, this thread has gotten a bit derailed. If you'd like to see: ... more frequent releases? then please step up and help with all the infrastructure needed to roll out test releases, including building _all_ the ports. A lot of people keep forgetting that a release is build all the ports for all the supported platforms. Does it need to be? I've been pushing a long time now to have a branched ports tree. If we have a stable version of the ports where only known-good changes are promoted then that frees us up quite a bit to redefine what a release is. that's another 'man hours' problem (branched ports) ... longer lifecycle? Then please step up and contribute patches for features for your favourite branch. As a developer doing this in my spare time I'm only really working on new features on -HEAD and maybe backporting fixes to 9.x. What _I_ would like is someone to take on the task of testing and backporting net80211/ath fixes to 8.x and 7.x. So you want to do all the fun stuff, and have someone else do your scut work? Good luck with that. :) Maybe what we need to do is redefine what it means to be a FreeBSD committer. From now on, your commit bit comes with XYZ privileges, but also ABC responsibilities. Sure, we'd lose some people, but what would we gain? Also, your premise is flawed. We (speaking generally) suck at supporting more than one -stable branch. We *really* suck at supporting three. Six months ago when the machinery was just beginning to spin up for 9.0-RELEASE I tried to get the PTB to reconsider. I was told that my concerns were invalid because it was basically ready to go as is. The plan I laid out at the time was to have no more than 2 stable branches extant at any given time. Lengthen the periods where each stable branch is supported, and terminate the oldest one when the newest one is released. I certainly think 9.0 was premature.. 8.x just started.. this should have been 8.3. ... longer branch lifecycle? Same as above. None of the developers are going to reject bugfixes and backported drivers to a legacy, stable branch. We may be a bit against the idea of porting entire new subsystems to legacy, stable branches - but if there's a good enough reason _and_ it's been tested _and_ there's a need for it - _I_ wouldn't say no. But committers already fail to MFC *existing* bug fixes to stable branches (even ones they generated). This is especially true for the older branches. So how is the idea of users generating more new bug fixes going to help? usually it's because they just forgot.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: * Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 7:12 PM, Devin Teske wrote: On Jan 17, 2012, at 7:05 PM, Matthew D. Fullerfulle...@over-yonder.net wrote: On Tue, Jan 17, 2012 at 06:49:02PM -0800 I heard the voice of Julian Elischer, and lo! it spake thus: 5 was not out on a limb for so long because it was a clusterfun, it was out there because it was a rework of how almost everything in the kernel worked. I'm not saying it was a cluster because it was a huge amount of very deep work; it's because that huge amount of very deep work completely gated our next release. Now, sure, changing external circumstances caught us with our pants down, and the tools we were using (like CVS) made it hard to do anything else. But that just means there were good reasons why it happened; doesn't make it less clusterfull :) The two circumstances (giant rework, and long period between major releases) are duals of each other. If we chop off giant piles of stuff to do for FreeBSD-next, it's going to take a very long time. And if we instead just set very long times (Jan 2017 for 10?! Insanity!) for -next, we're going to end up with giant reworks and huge differences. And _both_ faces are very bad. The one means we wait forever for any new work, and the other means that it takes enormous amounts of work as a user to transistion across the barrier. the trouble with 5 was that it had to be all-or-nothing. there is no such thing as a partly SMP system. (well, not one that you'd want to run). the size of the giant pile of stuff was not of our choosing. We could adopt a cycle similar to the Linux Kernel... Odd numbered releases are experimental while even numbered releases are stable (ducks for flying fruit) _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/16/12 3:32 PM, William Bentley wrote: I also echo John's sentiments here. Very excellent points made here. Thank you for voicing your opinion. I was beginning to think I was the only one who felt this way. [...] We seem to have lost our way around the release of FreeBSD 7. I am all in favor of new features but not at the risk of stability and proper life cycle management. Are me and John the only people that feel this way or are we among the minority? -Will It pretty much boils down to one thing.. man power.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Hardware supported by ng_frame_relay?
On 1/13/12 11:00 PM, Jan Mikkelsen wrote: Hi, I'm looking to upgrade a system running frame relay over a Sangoma A101 card and WANPIPE. Sangoma do not support FreeBSD anymore, so I'm looking for alternatives. What hardware does ng_frame_relay support now that ar(4) and sr(4) are not in FreeBSD 9? Specifically, will ng_frame_relay work with a Digium TE121 and ports/dahdi-kmod? Any suggestions welcome, G.703, X.21 or V.35 interfaces OK. Unfortunately, with the advent of Ethernet connected internet feeds (e.g. dsl, cable etc), plain synchronous interfaces have become almost irrelevant for most of the developers. If you can find a card that would have been usable with the ar or sr drivers and you have one for testing, we could possibly resurrect it with your help, but none of the current developers have such a card.. (that I know of). Thanks, Jan Mikkelsen___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Processes' FIBs
On 1/13/12 4:27 AM, Kostik Belousov wrote:
On Thu, Jan 12, 2012 at 10:44:51PM -0800, Julian Elischer wrote:
On 1/12/12 6:04 AM, Oliver Fromme wrote:
Bjoern A. Zeeb wrote:
On 11. Jan 2012, at 15:06 , Oliver Fromme wrote:
I'm currently looking at the source code of ps, but adding
a field for the FIB isn't as trivial as I thought because
ps only sees struct kinfo_proc (via sysctl kern.proc.*)
which doesn't contain the FIB. procstat does the same.
I'm currently trying to write a patch that copies p_fibnum
from struct proc to struct kinfo_proc (just like p_nice,
for example). Does that make sense? If so, does the patch
below look reasonable? (I've made it on a stable/8 system,
but it should apply to 9 and 10, too.)
I am not sure it makes too much sense in ps. It might make sense in
sockstat maybe?
Well, every process has a default FIB number (p_fibnum in
struct proc). It is a property of the process, just like
the nice value for example. So I think it makes sense for
ps to be able to display it if the user asks for it. This
is the piece of information that I need.
On the other hand, sockstat displays open sockets only.
Of course, an internet socket has a FIB number associated
with it, too, so sockstat could display it. But that
would be a completely different piece of information,
and it wouldn't solve the actual problem that I'm currently
facing.
I hadn't considered that a process would want to see the fib of another.
but of course it makes sense.
I see no problem the the attached patch except that it doesn't fix the
man page for ps and setfib(2) or setfib(8) (or is it 1?)
etc.
if there are no objections, I can add this when it has been polished..
The patch misses compat32 bits and breaks compat32 ps/top.
I guess that would be polishing :-)
Best regards
Oliver
--- ./sys/sys/user.h.orig 2011-07-12 14:23:54.0 +0200
+++ ./sys/sys/user.h2012-01-11 15:35:50.0 +0100
@@ -83,7 +83,7 @@
* it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and
* function kvm_proclist in lib/libkvm/kvm_proc.c .
*/
-#defineKI_NSPARE_INT 9
+#defineKI_NSPARE_INT 8
#define KI_NSPARE_LONG 12
#define KI_NSPARE_PTR 6
@@ -177,6 +177,7 @@
*/
charki_sparestrings[68];/* spare string space */
int ki_spareints[KI_NSPARE_INT];/* spare room for growth */
+ int ki_fibnum; /* Default FIB number */
u_int ki_cr_flags;/* Credential flags */
int ki_jid; /* Process jail ID */
int ki_numthreads; /* XXXKSE number of threads in total
*/
--- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.0 +0200
+++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.0 +0100
@@ -775,6 +775,7 @@
kp-ki_swtime = (ticks - p-p_swtick) / hz;
kp-ki_pid = p-p_pid;
kp-ki_nice = p-p_nice;
+ kp-ki_fibnum = p-p_fibnum;
PROC_SLOCK(p);
rufetch(p,kp-ki_rusage);
kp-ki_runtime = cputick2usec(p-p_rux.rux_runtime);
--- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.0 +0200
+++ ./bin/ps/keyword.c 2012-01-11 15:44:27.0 +0100
@@ -90,6 +90,7 @@
NULL, 0},
{etime, ELAPSED, NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL,
0},
{f, F, NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, x, 0},
+ {fib, FIB, NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, d, 0},
{flags, , f, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{ignored, , sigignore, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{inblk, INBLK, NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Processes' FIBs
On 1/12/12 6:04 AM, Oliver Fromme wrote:
Bjoern A. Zeeb wrote:
On 11. Jan 2012, at 15:06 , Oliver Fromme wrote:
I'm currently looking at the source code of ps, but adding
a field for the FIB isn't as trivial as I thought because
ps only sees struct kinfo_proc (via sysctl kern.proc.*)
which doesn't contain the FIB. procstat does the same.
I'm currently trying to write a patch that copies p_fibnum
from struct proc to struct kinfo_proc (just like p_nice,
for example). Does that make sense? If so, does the patch
below look reasonable? (I've made it on a stable/8 system,
but it should apply to 9 and 10, too.)
I am not sure it makes too much sense in ps. It might make sense in
sockstat maybe?
Well, every process has a default FIB number (p_fibnum in
struct proc). It is a property of the process, just like
the nice value for example. So I think it makes sense for
ps to be able to display it if the user asks for it. This
is the piece of information that I need.
On the other hand, sockstat displays open sockets only.
Of course, an internet socket has a FIB number associated
with it, too, so sockstat could display it. But that
would be a completely different piece of information,
and it wouldn't solve the actual problem that I'm currently
facing.
I hadn't considered that a process would want to see the fib of another.
but of course it makes sense.
I see no problem the the attached patch except that it doesn't fix the
man page for ps and setfib(2) or setfib(8) (or is it 1?)
etc.
if there are no objections, I can add this when it has been polished..
Best regards
Oliver
--- ./sys/sys/user.h.orig 2011-07-12 14:23:54.0 +0200
+++ ./sys/sys/user.h2012-01-11 15:35:50.0 +0100
@@ -83,7 +83,7 @@
* it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and
* function kvm_proclist in lib/libkvm/kvm_proc.c .
*/
-#defineKI_NSPARE_INT 9
+#defineKI_NSPARE_INT 8
#define KI_NSPARE_LONG 12
#define KI_NSPARE_PTR 6
@@ -177,6 +177,7 @@
*/
charki_sparestrings[68];/* spare string space */
int ki_spareints[KI_NSPARE_INT];/* spare room for growth */
+ int ki_fibnum; /* Default FIB number */
u_int ki_cr_flags;/* Credential flags */
int ki_jid; /* Process jail ID */
int ki_numthreads; /* XXXKSE number of threads in total */
--- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.0 +0200
+++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.0 +0100
@@ -775,6 +775,7 @@
kp-ki_swtime = (ticks - p-p_swtick) / hz;
kp-ki_pid = p-p_pid;
kp-ki_nice = p-p_nice;
+ kp-ki_fibnum = p-p_fibnum;
PROC_SLOCK(p);
rufetch(p,kp-ki_rusage);
kp-ki_runtime = cputick2usec(p-p_rux.rux_runtime);
--- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.0 +0200
+++ ./bin/ps/keyword.c 2012-01-11 15:44:27.0 +0100
@@ -90,6 +90,7 @@
NULL, 0},
{etime, ELAPSED, NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0},
{f, F, NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, x, 0},
+ {fib, FIB, NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, d, 0},
{flags, , f, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{ignored, , sigignore, 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{inblk, INBLK, NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Using symbolic execution for analyzing scheduler performance?
On 12/30/11 11:34 PM, arrowdodger wrote: On Sat, Dec 31, 2011 at 4:32 AM, Julian Elischer jul...@freebsd.org mailto:jul...@freebsd.org wrote: On 12/30/11 9:52 AM, arrowdodger wrote: - OS kernel calls scheduler functions in some defined order. The OS doesn't really call the scheduler in that way. all sorts of threads of execution jump into the scheduler from all sorts of places and the internal state of the scheduler changes with these calls. Sometimes those calls never return, and sometimes they return a long time later.. As I said, it's a very complicated interface. Oh, threads. Yes, this imposes unimaginable complexity on what i'm proposing. What do you think? Does it make any sence, or i should just return under my rock? no, come out from your rock.. If you are interested in the scheduler, by all means go and read it and try and understand it, and then come back to us if you do have ideas. Yeah, i think it's what i should've done in first place, before dumping by brain to ML. Okay, i will try to get an idea of how schedulers work in detail and after that will try to find parts of it, which can be automatically verified. BTW, is there any documentation on how write schedulers for FreeBSD, or at least, ULE specification? there is a paper that was presented somewhere on ULE, but the best source of information is of course the code.. start by reading the 4bsd scheduler.. as it's simpler.. I don't think your idea is really bad but I think you underestimate the difficulty of the task. PS: Sorry for my english, i hope you understood what i've been trying to say. your english is fine.. what do you normally speak? Russian. there are a lot of russian developers so you should be able to find someone if you need explanations in Russian.. (and you are not really 6 years old, are you? :-) Yeah, i've grown up a little, since then. Thanks for your insight! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Using symbolic execution for analyzing scheduler performance?
On 12/30/11 9:52 AM, arrowdodger wrote: Hi. First, let me put a little disclaimer: I have absolutely no CS education and any degree in science, no idea on how OS kernels and CPU schedulers are implemented and working. Moreover, i haven't even know math at the level needed to talk about what i'm proposing. What i'm going to propose may be just nonsence. I've assumed that: - Scheduler in FreeBSD is just a bunch of code, which implemens some interface. yes, though it is very complicated interface, and some of it is not explicit. - This implementation is self-contained - it doesn't call any other kernel functions and do not depend on other state except itself. That is not really true. There are all sorts of interactions. Not all of them are as simple as a call. - OS kernel calls scheduler functions in some defined order. The OS doesn't really call the scheduler in that way. all sorts of threads of execution jump into the scheduler from all sorts of places and the internal state of the scheduler changes with these calls. Sometimes those calls never return, and sometimes they return a long time later.. As I said, it's a very complicated interface. If these assumptions are true, it may be possible to compile scheduler code as userland code and link it with sort-of driver, which would call scheduler functions in same way as real kernel does. So we get a statically-linked executable, which would emulate working kernel for the scheduler. yes that would certainly be true from some perspective. But it would be quite a bit of work. Now we will be using KLEE [1] - a virtual machine for symbolic execution. It uses SAT solvers to reason about veriables values. In our driver code we insert calls to klee_assert() after every call to scheduler function to make KLEE dump current symbolic restrictions on scheduler's internal state values. Finally, we mark all data, describing scheduler state as symbolic and run program on KLEE. As result, we get (i hope so) a set of all possible states in which scheduler can ever be in form of KLEE test file (.ktest). A test is represented by descriptions of what value each variable can have in the current context. So, any of generated states is not intersecting with each other. It is a nice goal but I can't see it happening.. I think that the scheduler is probably a bit too complicated.. the automatic testing and verification woudl be nice but my head hurts thinking about it :-) Now it's possible to concretize symbolic values for each test and save it as normal executable. You may think of it as a model of how our scheduler is functioning. Now we can symbolically execute these binaries again, but for now marking as symbolic all external data from scheduler point of view. This way we can track and debug scheduler decisions in any circumstance. In other words: 1. All possible scheduler states are being found. 2. Identical states are being thrown away. // done by KLEE 3. For each state model scheduler behavior for every input (and skipping modellings, which yields same results). I'm not sure if it can help to solve current ULE problems, but it should really help debugging scheduler during development. I don't think that the scheduler needs debugging so much as the specification of it needs thinking.. The scheduler has teh problem of trying to make decisions about what to do in the future from imperfect knowledge of the past, and no knowledge of the future. What do you think? Does it make any sence, or i should just return under my rock? no, come out from your rock.. If you are interested in the scheduler, by all means go and read it and try and understand it, and then come back to us if you do have ideas. I don't think your idea is really bad but I think you underestimate the difficulty of the task. PS: Sorry for my english, i hope you understood what i've been trying to say. your english is fine.. what do you normally speak? (and you are not really 6 years old, are you? :-) [1] http://klee.llvm.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysctl variable question
On 12/18/11 12:18 PM, Fernando Apesteguía wrote: Hi all, I'm writing a small module just for fun. I would like to have two variables: - pid of type unsigned int and RW so the user can set a pid - process_name as a string RD that will display the process name associated to that pid (or a message if the pid doesn't exist anymore) this is dangerous as there are some places in the kernel where processes are referenced by pid, so changing it may break kernel assumptions. My problem is with the handler functions. For process_name, as it is read only, I wrote a simple handler that works fine. However, I want to write another one for pid so I can sanitize the input (avoiding pids 0 and so). As I understand, the handler I specify with SYSCTL_OID will be called for both reads and writes. But, how can I tell what kind of operation is it, so I know if I have to use SYSCTL_OUT or SYSCTL_IN? I tried to have a look at sysctl_handle_int but I don't fully understand what is going on with the arg1 parameter. What is it for? Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: mmap implementation for cdev
On 12/3/11 12:42 AM, Filippo Sironi wrote: Dear all, I've a strange problem I cannot understand... I implemented a piece of code within the FreeBSD 7.2 kernel that basically allocate a per-thread memory page to store a certain amount of information that must be read and written without crossing user to kernel and kernel to user boundaries. To read and write the memory page I decided to allocate it in kernel space and then mmap'ing it to user space using a virtual cdev as an entry point for user space threads. The implementation of the mmap I came up with is really trivial, I basically do: *paddr = vtophys(curthread-private_info); Now for the problem. I enter the mmap and private_info is the correct kernel space virtual address, each thread as its own address and the physical address - returned by vtophys - is different too. The problem is that when I come back to user space all the threads write in memory page mapped by the first thread that called the mmap leaving their memory pages untouched. This problem bugs me but I cannot find a solution. I don't really understand the behavior. each thread needs to store a different address as the base of it's memory.. the memory map of a process is just that.. the memory map of the PROCESS All threads see the same map. Any ideas? Thanks a lot, Filippo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: mmap implementation for cdev
On 12/3/11 2:37 AM, Filippo Sironi wrote: I need to access the memory both from user space and kernel space, I cannot do that (simply) with an mmap or thread-specific storage if I recall correctly. that's how mmap works.. if you give it pages to expose to the user, you can still access them from in the kernel. you just have to make the threads in user land access different addresses. On 03/dic/2011, at 11.00, Poul-Henning Kamp wrote: In messagea842c229-1846-408a-999a-9347770ef...@gmail.com, Filippo Sironi wri tes: Why don't you just use mmap(2) ? I couldn't see anything you couldn't do with it. There's also support in pthread for thread specific storage, which should be your first choice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Communication between kernel and userspace via local socket
On 11/17/11 11:40 AM, Maxim Ignatenko wrote: Julian Elischer wrote: On 11/16/11 12:55 AM, Ed Schouten wrote: * Maxim Ignatenkogelraen...@gmail.com, 2015 21:18: I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and looking for most convenient way to establish communication between userspace processes and kernel part. Communication pattern best fits to listening PF_LOCAL socket opened from kernel and userspace processes connecting to it. What's wrong with a character device? you can't easily have a different character device depending on which jail you are in.. (well, you can but it gets tricky).. see the problem with /dev/pflog and vimages. Maxim, look at the usage of sockets with netgraph ng_socket node.. also divert sockets. Did you meant ng_ksocket? I've looked on it, but in case of ng_ksocket connections accepted upon receiving control message NGM_KSOCKET_ACCEPT, but I need to accept connections without such punch. As far as I understand, I need to spawn kernel process or thread which will listen for incoming connections and respond to requests, just like normal network daemon does, but I don't know how to do this. divert(4) will not do the job, since packets written to divert socket goes to IP stack. No I meant ng_socket.. you wanted to communicate between userland and kernel. that ng_socket is the interface between kernel and userland for netgraph. I also meant, look at how the divert sockets create the sockets, not that you should use divert. ng_ksocket is something else. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Communication between kernel and userspace via local socket
On 11/16/11 12:55 AM, Ed Schouten wrote: * Maxim Ignatenkogelraen...@gmail.com, 2015 21:18: I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and looking for most convenient way to establish communication between userspace processes and kernel part. Communication pattern best fits to listening PF_LOCAL socket opened from kernel and userspace processes connecting to it. What's wrong with a character device? you can't easily have a different character device depending on which jail you are in.. (well, you can but it gets tricky).. see the problem with /dev/pflog and vimages. Maxim, look at the usage of sockets with netgraph ng_socket node.. also divert sockets. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Does anyone use nscd?
On 10/4/11 9:51 AM, Dag-Erling Smørgrav wrote: Trond Endrestøltrond.endres...@fagskolen.gjovik.no writes: It's in daily use at Gjøvik Technical College (Fagskolen i Gjøvik), here in Norway. Both the mail and web servers authenticates our users by LDAP, and nscd certainly speeds up the lookups. OK. No trouble with clients dying of SIGPIPE? I could never reproduce the bug, but both users who reported problems used ldap, and I don't have an LDAP server to test against, so I thought it might be specific to LDAP. DES I had never heard of it until now but it looks as though I could have used it several times in the past. We should have people announce new features just like new committers. Hi, my name is nscd, I cache data that is accessed through the nsswitch system etc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: dtrace in FreeBSD 7.2
On 9/19/11 9:17 AM, Charlie Martin wrote: Dude, you say that like it was an option. It's understood about the realities of commercial decisions, however, if you really want to trace APPS that means user space dtrace and 7.2 just doesn't have the hooks to do non-kernel dtrace. As a side note, realize that Dtrace support in FreeBSD had a serious problem a couple of years ago when the lead developer suddenly dropped dead (Very literally, to out great sadness), and it took a while for alternative resources to fill the gap. On 2011-09-16 18:46, Matthias Andree wrote: Am Freitag, den 16.09.2011, 14:30 -0600 schrieb Charlie Martin: I need to add some custom static dtrace probes in 7.2 apps; the online documentation refers only to 9 however. Can someone tell me how to replace what's done in bsd.dtrace.mk for 7.2? FreeBSD 7.2 is quite old and wasn't under extended support, hence it is no longer supported. Consider upgrading. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: dtrace in FreeBSD 7.2
On 9/16/11 1:30 PM, Charlie Martin wrote: I need to add some custom static dtrace probes in 7.2 apps; the online documentation refers only to 9 however. Can someone tell me how to replace what's done in bsd.dtrace.mk for 7.2? I' am not sure that user space dtrace suport was available in 7.2.. My memory is that it came in 8.x but I'm not certain. Thanks Charlie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FIB separation
On 7/16/11 5:43 AM, Vlad Galu wrote: Hello, A couple of years ago, Stef Walter proposed a patch[1] that enforced the scope of routing messages. The general consesus was that the best approach would be the OpenBSD way - transporting the FIB number in the message and letting the user applications filter out unwanted messages. Are there any plans to tackle this before 9.0? I haven't really been following this unfortunately but I see at least part got done. (ifconfig) is there anything we need to do before 9.0 that is small but would make a big difference? (i.e. fixes, tweaks) Julian One thing that I haven't done and I only recently remembered, was the ability to have a socket inherit it's fib from the incoming connection SYN instead of from the socket opening process. (at least I am pretty sure I never got that done. (must go check)). Thanks, Vlad [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VMWare/Virtualbox virtio network drivers?
On 9/6/11 8:03 PM, Adrian Chadd wrote: On 7 September 2011 09:32, Adam Vande Moreamvandem...@gmail.com wrote: On Tue, Sep 6, 2011 at 7:50 PM, Stephen Hocking stephen.hock...@gmail.comwrote: Am wondering if anyone has done drivers the these sorts of network interfaces that are offered by VMWare Virtual box. I know that on some Linux VMs I run, performance went from 20MB/s to 30MB/s to an NFS server which I swicthed to the virtio network interfaces. There is this patch, but it didn't get committed for some reason. http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022036.html Has this been used/tested by others? I see a reply from you. The BHyve guys are implementing virtio drivers and have looked at both these drivers and others. I don't know what their plans are.. you should send to virtualizat...@freebsd.org (cc'd and redirected) to get up to date info. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FIB separation
On 7/16/11 9:19 AM, Alexander V. Chernikov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiroki Sato wrote: Vlad Galud...@dudu.ro wrote ina718adb2-ec52-462c-a114-85053f1b2...@dudu.ro: du Hello, du du A couple of years ago, Stef Walter proposed a patch[1] that enforced du the scope of routing messages. The general consesus was that the best du approach would be the OpenBSD way - transporting the FIB number in the du message and letting the user applications filter out unwanted du messages. du du Are there any plans to tackle this before 9.0? I am looking into this and investigating other possible extensions in rtsock messages such as addition of a fib member to rt_msghdr. I am not sure it can be done before 9.0, though... Actually there were an off-list discussion with bz@ and julian@ about interface fibs and rtsock changes several weeks ago. Initial messages: http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029040.html I've got 3 different patches: 1) straight forwarded kern/134931 fix (no fib in rtsock, no breaking ABI, send to bz@) just got back from vacation in hungary so catching up...: Didn't he commit it? bz?? 2) adding fib in rtsock with rtsock versioning and other ABI keeping tricks 3) adding special RTA which can contain TLV pairs, with single defined TLV with routing socket As a result of discussion, first patch was sent to bz@. Since patches from kern/134931 are outdated attaching it here. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Jails: Setting different times in jails
On 7/3/11 1:16 AM, grarpamp wrote: Would be nice to be able to set different times in different jails. All jails would tick in step with the system. But each jail could have it's birthtime set specifically via jail(8), jail(2), etc. Either by specification of a specific time, or an offset from the current true system time. ie: jail(8): -t [-|+]seconds Child jails would offset from their parent, not the system. Internally, gettimeofday, filesystem timestamps, and any other userland interfaces would be hooked and adjusted by referencing a table of jail ID's and their offsets. Similar to how setting TZ or /etc/localtime effects a timezone offset. But transparent and undetectable to the jail unless set as visible by the invoker. Useful for creating alternate histories, testing time dependant protocols and applications, forensics, pen testing, etc. possibly achievable in libc? in any case file this idea somewhere.. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] __FreeBSD_kernel__
On 7/3/11 7:35 AM, Alexander Kabaev wrote: __linux__ is exactly what __FreeBSD__ is and dies not identify kernel but rather Linux as whole OS, whatever that might be these days. There does not appear to be an universal macro that identifies environment as using Linux kernel regardless of the rest of components used (say, to identify Android and Ubuntu or something embedded with ucLibc as running Linux kernel with different userland implementations). I thought it was (__linux__ __KERNEL__) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Testing a change to printf(9)
On 6/7/11 12:57 PM, Dieter BSD wrote: I've been working on fixing problems with printf(9), log(9) and related functions. Today I tried converting printf(9) to write to the log rather than directly to the console, unless the log is not open, in which case the message is also sent to the console. Printf(...) is now the same as log(LOG_INFO, ...). oh please no! from my perspective, I want my printf output to go to the console. immediately, regardless of where it goes after that. I don't care if there is or is not a log. I do NOT want to EVER have the problem I've had on linux where the last vital bit of output never made it out before the system stopped. once it's been shown on the console I don't care what happens to it.. I commented out the line in /etc/syslog.conf that sends some log messages to the console. In multiuser mode, normal printfs go to log, but not the console, as expected. Bootup messages, shutdown messages, and panic messages all show up on the console as expected. Are there any other special cases to test? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Testing a change to printf(9)
On 6/7/11 6:33 PM, Dieter BSD wrote: I've been working on fixing problems with printf(9), log(9) and related functions. Today I tried converting printf(9) to write to the log rather than directly to the console, unless the log is not open, in which case the message is also sent to the console. Printf(...) is now the same as log(LOG_INFO, ...). oh please no! from my perspective, I want my printf output to go to the console. immediately, regardless of where it goes after that. I don't care if there is or is not a log. I do NOT want to EVER have the problem I've had on linux where the last vital bit of output never made it out before the system stopped. once it's been shown on the console I don't care what happens to it.. Printfs to the console cause data loss. Easily repeatable. Absolutely unacceptable. You are welcome to fix the actual underlying problem. I would love to see the underlying problem fixed! I've asked a few times before, but I'll ask again. Why does a driver for one piece of hardware have to block interrupts for all hardware? I thought changing from spl to mutex was supposed to fix this? My changes do not prevent a sysadmin from having printf output go to the console, it gives them a choice. Currently there is no choice. NO! a kernel printf goes to the console however it may be redirected. It MAY also decide to go somewhere else. But not if it means unreliable delivery to the serial port. The console MUST get the output in a completely reliable manner unless it's been disabled. do not do anything that gets between the console and the problem. if you want to send it on to some other secondary sevice such s a log, then disable the console and take the priority service but do NOT do any of the silly tricks that some people have tried in the past like making the console just one of several things on a mux. all with equal ability to screw up the other. I want the console to be the last refuge in a dying system. if a send a char there I KNOW it's gone out. it is synchronous and it doesn't lie. if you don't want a reliable console then turn it off but don't make something else that is unreliable and call it the console. call it anything else but don't screw up the console. I commented out the line in /etc/syslog.conf that sends some log messages to the console. In multiuser mode, normal printfs go to log, but not the console, as expected. Bootup messages, shutdown messages, and panic messages all show up on the console as expected. Are there any other special cases to test? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RELEASE] New Boot-Loader Menu
On 5/29/11 2:53 PM, Devin Teske wrote: On May 4, 2011, at 8:57 AM, Devin Teske wrote: On May 3, 2011, at 9:06 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 08:45:14PM -0700, Devin Teske wrote: On Apr 30, 2011, at 8:11 PM, Jason Hellenthal wrote: Devin, On Sat, Apr 30, 2011 at 04:00:47PM -0700, Devin Teske wrote: Would be nice: uname -v of the kernel it will boot. That's a bit more technically challenging. I'll have another look at the FICL words available, but I don't recall if there was a way to crawl the object space of the items loaded with ``load'' (looking for the uname). I'm open to suggestions if you had an idea of how to do this in Forth -- else I'd think this would need to be a loader(8) modification. How about forgetting a mention of unmae ... instead look into if we can support some sort of bootcode versioning to be displayed on the screen. This would serve to be very helpful in the future when for say a new version of bootcode for ZFS has to be installed then it would be easy for announce@ to simply say A new version of ZFS has been MFCd and requires boot version= X. To find out your version please see the bottom right hand corner of your boot screen. I would place a pretty good bet that loader(8) could be modified to export some sort of versioning of the bootcode to make this a easier stance for the user to gather information before a upgrade. Piece of cake! If you give me a loader(8) that exports a version environment variable, I'll give the Forth functionality in mere seconds. It's already been developed (but was not packaged). I have a module named version.4th which prints the value of the version environment variable at the bottom-right of the screen underneath the beastie logo. Since you mention this, I'll add the code to the next package and if/when loader(8) ever exports a version environment variable, it will just magically appear. How's that sound? Sounds perfect! One minor adjustment... can we make that environment variable loader_version instead of version? The code is already in for loader_version. Whatever string you export into that environment variable will be displayed on-screen at bottom-right, right-justified. The code for thew new menu has been committed to HEAD. http://svnweb.freebsd.org/base?view=revisionrevision=222417 Now... Who wants to make the necessary patch to loader(8) to export $loader_version text? Or maybe a suggestion on another list worth including on this? I suggest this move to -current since it is checked on there, and a port be kept for 8.x/7.x Devin, a fix was made at 222450 as it was broken for ppc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Active slice, only for a next boot
On 5/27/11 11:34 AM, Warner Losh wrote: On May 27, 2011, at 10:47 AM, rank1see...@gmail.com wrote: - Original Message - From: Alexander Bestarun...@freebsd.org To: rank1see...@gmail.com Cc: hack...@freebsd.org Date: Fri, 27 May 2011 13:47:54 + Subject: Re: Active slice, only for a next boot On Fri May 27 11, rank1see...@gmail.com wrote: Idea is ... I have i.e; 3 slices, of which first is active. Now I wana set slice 2 active, but only for a one/next boot. Once slice 2 is booted and system is shutdown or rebooted, once again, first slice is active and booted, without user's intervention. Is this possible or should be implemented? nextboot(8) USED to do this before it was broken by someone to look into the filesystem for it's next boot hint which is obviously broken if you are trying to get to another filesystem because the main one is broken. take a look at the gpart(8) manual, expecially the ATTRIBUTES section. if you are running with a GPT scheme you can use the bootonce attribute to do exactly what you asked for. cheers. alex Thanls, but I need it for MBR. gpart works with MBR. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Active slice, only for a next boot
On 5/28/11 6:06 AM, rank1see...@gmail.com wrote: And how about this: # boot0cfg -o noupdate -s 1 Now when you choose to hit slice 2, it is only for a this one boot. Next and each boot, defaults to slice 1 Problem is, that you must see, early bootstrap, to manually choose, so this won't work on a remote server. This requires: a) physicall access or b) ssh access to the remote box, which is conected via serial cable, to your server. Anyone has any idea, for a case of a remote server, which is accessible over ssh, only when it is up? pull the old bootblocks from about 2000 and use them. and nextboot as well they do exactly what you want. OR ask Doug Ambrisko (cc'd) for a copy of them that he still uses at work. He may have updates to make them work with modern systems that would save you time. the old nextboot(8) stored instructions as to what to do on block 1 of the drive (you can make it a small 1 block partition if you want). Actually it stored a series of them, NULL separated. On each boot the boot 0 bloter would read the first (after skipping any nulls) and then write Nulls over what it just read and write it back to block 1. so it would progress gradualy boot by boot over the sequence written by nextboot. it would pass on the stack, what it had read to boot1. the format was hd(1,a)/boot/loader(for example) personally I would like to hav ethis capabiltiy back because it's stupid rely on a possibly dead filesystem to get around booting from the possibly dead filesystem. by default we used to have a /etc/rc entry that would rewrite the 'current' setup several times on successful boot, followed by a couple of alternate boot targets. If boot failed a coupke of times it would automatically boot from the second drive or from another partition, .. Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Active slice, only for a next boot
On 5/28/11 4:06 AM, Chris Rees wrote: On 28 May 2011 10:04, Julian Elischer jul...@freebsd.org mailto:jul...@freebsd.org wrote: On 5/27/11 11:34 AM, Warner Losh wrote: On May 27, 2011, at 10:47 AM, rank1see...@gmail.com mailto:rank1see...@gmail.com wrote: - Original Message - From: Alexander Bestarun...@freebsd.org mailto:arun...@freebsd.org To: rank1see...@gmail.com mailto:rank1see...@gmail.com Cc: hack...@freebsd.org mailto:hack...@freebsd.org Date: Fri, 27 May 2011 13:47:54 + Subject: Re: Active slice, only for a next boot On Fri May 27 11, rank1see...@gmail.com mailto:rank1see...@gmail.com wrote: Idea is ... I have i.e; 3 slices, of which first is active. Now I wana set slice 2 active, but only for a one/next boot. Once slice 2 is booted and system is shutdown or rebooted, once again, first slice is active and booted, without user's intervention. Is this possible or should be implemented? nextboot(8) USED to do this before it was broken by someone to look into the filesystem for it's next boot hint which is obviously broken if you are trying to get to another filesystem because the main one is broken. Doesn't sound that useful to me- I think of the main use for nextboot being to try new kernels on a one-time basis. If you're rescuing a broken filesystem surely it's better to just set another slice active? try using it on an appliance it has to recover on its own from a complete filesystem screwup. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Active slice, only for a next boot
On 5/28/11 11:10 AM, Julian Elischer wrote: On 5/28/11 4:06 AM, Chris Rees wrote: On 28 May 2011 10:04, Julian Elischer jul...@freebsd.org mailto:jul...@freebsd.org wrote: On 5/27/11 11:34 AM, Warner Losh wrote: On May 27, 2011, at 10:47 AM, rank1see...@gmail.com mailto:rank1see...@gmail.com wrote: - Original Message - From: Alexander Bestarun...@freebsd.org mailto:arun...@freebsd.org To: rank1see...@gmail.com mailto:rank1see...@gmail.com Cc: hack...@freebsd.org mailto:hack...@freebsd.org Date: Fri, 27 May 2011 13:47:54 + Subject: Re: Active slice, only for a next boot On Fri May 27 11, rank1see...@gmail.com mailto:rank1see...@gmail.com wrote: Idea is ... I have i.e; 3 slices, of which first is active. Now I wana set slice 2 active, but only for a one/next boot. Once slice 2 is booted and system is shutdown or rebooted, once again, first slice is active and booted, without user's intervention. Is this possible or should be implemented? nextboot(8) USED to do this before it was broken by someone to look into the filesystem for it's next boot hint which is obviously broken if you are trying to get to another filesystem because the main one is broken. Doesn't sound that useful to me- I think of the main use for nextboot being to try new kernels on a one-time basis. If you're rescuing a broken filesystem surely it's better to just set another slice active? try using it on an appliance it has to recover on its own from a complete filesystem screwup. i.e. a 100% recovery with NO HUMAN INTERVENTION. even in the case of a dead/dieing drive. (requires that bios has drive boot order feature) I will add that this functionality is so useful that several companies still maintain the old bootblocks internally (e.g. cisco) The new functionality was introduced without an consultation and the old functionality just 'lost'. Which was just bad design and project management.. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: who is in swap?
On 5/20/11 5:32 AM, Bill Moran wrote: In response to Daniel Branissda...@cs.huji.ac.il: no, Who's on 3rd ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: who is in swap?
On 5/20/11 2:57 PM, Sean C. Farley wrote: On Fri, 20 May 2011, Julian Elischer wrote: On 5/20/11 5:32 AM, Bill Moran wrote: In response to Daniel Branissda...@cs.huji.ac.il: no, Who's on 3rd No. I Don't Know is on 3rd. Who's on 1st. I don't KNOW who's on 1st! Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Freebsd And the sun x4440
On 5/16/12 5:42 PM, Mark Saad wrote: All I am setting up 3 sun x4440 with freebsd 7.3 amd64 . The severs have 4x 4-core opterons and 128G of ram each . Once the servers boot they are a good fit for what we are doing and preform well . The odd thing I am seeing is a long delay in boot up . Once in the initial loading of the kernel at the | for 1-2 mins . Then again shortly after printing the kernel banner freebsd 7.3-release etc etc etc . This delay is about 1-2 mins as well. So my question does any one know what I could do to speed up the boot up ? I suspect the first delay is due to a serial device probe the second is a mystery . also the bios load up time is about 5 mins on this box does anyone have any ideas on speeding that up ? I'd suspect that all three are some sort of memory probe or test. you might also check they are not trying to do a PXE boot first. mark saad nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: OpenGrok for FreeBSD
On 5/17/11 1:35 AM, Zafer Aydoğan wrote: 2011/5/13 Zafer Aydoğanza...@aydogan.de: Zafer. Hmm... there seems to be very little interest so far. Although this tool is mainly useful for developers, what is the correct mailing list to announce it ? The service seems to be good but most people who are developers have their own ways of acting with the sources already and asking them to change their habits built up over many years is hard to do.. people who are looking at sources using a web sute are probably already using fxr.watson.org that doesn't mean that it's not useful, just that it takes people a while to start using a new service.. how does it disambiguate teh same finction names in a kernel and in a /bin program? Zafer. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFS mount inside jail fails
On 5/17/11 1:17 PM, Alexander Leidinger wrote: On Tue, 17 May 2011 12:56:40 -0700 Sean Brunosean...@yahoo-inc.com wrote: Silly thing I ran into today. User wanted to NFS mount a dir inside a jail. After I groaned about the security implication of this, I noted that there is a sysctl that looks like it should allow this. Namely, security.jail.mount_allowed. I noted that setting this follows a path that *should* have allowed this silly thing to happen, except that the credentials in the nfsclient were not setup correctly. As you noticed, this is supposed to allow to mount inside a jail, IF the FS you want to mount is marked as secure/safe to do so. Nearly no FS is marked as such, as nobody wants to guarantee that it is safe (root in a jail should not be able to panic a system by trying to mount a corrupt/malicious FS-image) and secure (not possible to get elevated access/privileges). For NFS there is theoretically the problem that the outgoing address on requests could be the one of the physical host instead of the IP of the jail. If this is true in practice, I do not know. This could be the reason why NFS is not marked with VFCF_JAIL. a vimage jail would not have that problem if we've done it right. Bye, Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [UPDATE] New Boot-Loader Menu -- version 1.3
On 5/12/11 2:14 PM, Devin Teske wrote: On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: Devin Teskedte...@vicor.com wrote: Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Devin, have you thought about writing a port [1]? I'd be happy to review it: port would be good for 8 it'll be in 9 by default (we just decided a the devsummit) (if there are no roadblocks) [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html I'm going to see if I can't make it perfectly acceptable for base first. If the final version gets rejected for submission to base, I'll turn to ports. On a side-note, it'd be a pretty interesting port... considering the fact that I'm already distributing it as a FreeBSD package (what would the Makefile for that port look like... a call to fetch followed by a call to pkg_add ?? lol -- are there other ports that already work like that?). Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Looking for resources to get started
On 4/22/11 10:58 AM, Robert Lorentz wrote: Hi, I'm very interested in getting started with FreeBSD development. My interests are wide but specifically core OS, performance, scheduling, cryptography, perhaps filesystems etc. I have seen the Ideas list and there is some good stuff there but those are fairly complex/large tasks. Where can I find something more basic to address to get myself familiar with the process of contributing? ok so the first things are: Find a way to get an updating image of the sources in your favourite SCM system, (svn, cvs, p4, git, hg) once you have that, get familiar with building kernels, booting new kernel images and how to recover when you screw it up.. that should take you a couple of weeks if you haven't already done so. then pick an area that interests you and just start playing with the code. Add printfs, learn to trace execution with gdb, dtrace, etc. Pretty soon you'll find something to fix, there are plenty of things to fix. Make a patch and submit it and get to know the procedure. Don't worry, things will LEAP out at you to be fixed :-) Get to know the people in the area you are playing with and discuss your changes and ideas with them. If you get too annoying by fixing too many things well they'll punish you by putting you up for your own commit privs. :-) This is not a company. No-one is going to assign you work.. do what you want. My motivation for contributing is to learn more about the FreeBSD kernel and core OS and to put my skills toward FreeBSD which I find interesting and worthwhile. I am knowledgable in C, scheduling, data interface, somewhat also in cryptography Thanks, Robert___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Kernel Tracking Question.. regarding kernel and boot files
On 4/9/11 2:51 PM, Chris Richardson wrote: On Sat, Apr 9, 2011 at 10:34 PM, Chuck Swigercswi...@mac.com wrote: Hi, Chris-- [ ...Reply-to: set to direct towards the most appropriate list... ] On Apr 9, 2011, at 8:31 AM, Chris Richardson wrote: I am totally new to FreeBSD. I was involved within project which will trace the kernel. I used ktrace but I could not get appropriate results about the files being opened. I don't see any of the boot files boot0-1 or 2 in the ktrace.out file. Where did they go? The bootstrap loader stages are what loads and runs the kernel. ktrace isn't available until afterwards, when the kernel is running. Is ktrace the best trace suite for freebsd kernel? Kinda depends on what you are doing. Setting up good logging and making userland interfaces for getting to useful information (cf vmstat, ps, iostat, etc) is more likely to be useful over the longer run. What about if I wanna see the interaction between boot process and kernel loading. either you run it under an emulator that allows you to single step it. or you just add a lot of printf() to the boot loader. (some parts are required to fit in small code sizes to adding prints will cause overflow..) best to read the docs and then the sources. then it wil become apparent to you what you want to find out. What about going through source code .. Is it better to use Combination of Ecllipse/Qemu and FreeBSD Source tree? Eclipse is an editor. If you like it in particular, free free to use it, otherwise pick something else you'd prefer to use for C code. Does this method will provide us with someway to see how booting process invokes the kernel to memory ? Any help will be appreciated. You're asking about the process here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html ...? Frankly, none of these are especially big, start by reviewing the source code for 'em. Yeah. this file provides me with the stages in theoretical way. How about implementing it using qemu to emulate livecd to see what is going on boot0. Do you have an idea about that ? Good Luck, Regards, -- -Chuck ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoc] Timeconter Performance Improvements
On 3/27/11 3:32 PM, Warner Losh wrote:
On Mar 26, 2011, at 8:43 AM, Jing Huang wrote:
Hi,
Thanks for you all sincerely. Under your guidance, I read the
specification of TSC in Intel Manual and learned the hardware feature
of TSC:
Processor families increment the time-stamp counter differently:
• For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4
processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
and for P6 family processors: the time-stamp counter increments with every
internal processor clock cycle.
• For Pentium 4 processors, Intel Xeon processors (family [0FH],
models [03H and
higher]); for Intel Core Solo and Intel Core Duo processors (family [06H], model
[0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo processors
(family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (family
[06H], display_model [17H]); for Intel Atom processors (family [06H],
display_model [1CH]): the time-stamp counter increments at a constant rate.
Maybe we would implement gettimeofday as fellows. Firstly, use cpuid
to find the family and models of current CPU. If the CPU support
constant TSC, we look up the shared page and calculate the precise
time in usermode. If the platform has invariant TSCs, and we just
fallback to a syscall. So, I think a single global shared page maybe
proper.
I think that the userspace portion should be more like:
int kernel_time_type) SECTION(shared);
struct tsc_goo tsc_time_data SECTION(shared);
switch (kernel_time_type) {
case 1:
/* code to use tsc_time_data to return time */
break;
default:
/* call the kernel */
}
I think we should avoid hard-coding lists of CPU families in userland. The
kernel init routines will decide, based on the CPU type and other stuff if this
optimization can be done. This would allow the kernel to update to support new
CPU types without needing to churn libc.
Warner
P.S. The SECTION(shared) notation above just means that the variables are in
the shared page.
As has been mentioned here and there, the gold-standard way for doing
this is for the kernel to export a special memory region
in elf format that can be linked to with exported kernel sanctioned
code snippets specially tailored for the cpu/OS/binray-format
in question. There is no real security risk to this but potential
upsides are great.
On Sat, Mar 26, 2011 at 10:12 PM, John Baldwinj...@freebsd.org wrote:
On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote:
On 2011-Mar-25 08:18:38 -0400, John Baldwinj...@freebsd.org wrote:
For modern Intel CPUs you can just assume that the TSCs are in sync across
packages. They also have invariant TSC's meaning that the frequency
doesn't change.
Synchronised P-state invariant TSCs vastly simplify the problem but
not everyone has them. Should the fallback be more complexity to
support per-CPU TSC counts and varying frequencies or a fallback to
reading the time via a syscall?
I think we should just fallback to a syscall in that case. We will also need
to do that if the TSC is not used as the timecounter (or always duplicate the
ntp_adjtime() work we do for the current timecounter for the TSC timecounter).
Doing this easy case may give us the most bang for the buck, and it is also a
good first milestone. Once that is in place we can decide what the value is
in extending it to support harder variations.
One thing we do need to think about is if the shared page should just export a
fixed set of global data, or if it should export routines. The latter
approach is more complex, but it makes the ABI boundary between userland and
the kernel more friendly to future changes. I believe Linux does the latter
approach?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoc] Timeconter Performance Improvements
On 3/25/11 1:24 AM, Peter Jeremy wrote: On 2011-Mar-24 17:00:02 +0800, Jing Huangjing.huang@gmail.com wrote: In this scenario, I plan to use both tsc and shared memory to calculate precise time in user mode. The shared memory includes system_time, tsc_system_time and factor_tsc-system_time. This sounds like a reasonable approach to me. Note that once we implement a shared page, there is probably a variety of other information we could usefully place on that page. SunOS 4.x included a page of shared memory per CPU. This was mapped as an array (indexed by CPU number) at one address and the page reflecting the current CPU was additionally mapped at another fixed address. This allowed a process to both refer to data on its CPU as well any CPU on the system. We also consider the CPU frequency, because tsc counter is related to it. When kernel changes CPU frequency, the shared memory should be update subsequently. Two issues with this, particularly on x86 without invariant TSC: - looking up the current CPU frequency may not be a cheap operation - the reported CPU frequency appears to be just an approximate value, rather than the actual TSC frequency. On 2011-Mar-24 21:34:35 +0800, Jing Huangjing.huang@gmail.com wrote: As I know, tsc counter is CPU specific. If the process running on a multi-core platform, we must consider switching problem. The one way, we can let the kernel to take of this. When switching to another CPU, the kernel will reset the shared memory according to the new CPU. I'm not sure what the cost of managing this page mapping will be. The second way, we can use CPUID instruction to get the info of current CPU, which can be executed in user mode ether. At the same time, the kernel maintains shared memory for each CPU. When invoke gettimeofday, the function will calculate precise time with current CPU's shared memory. This approach suffers from a race condition between the CPUID instruction and accessing the appropriate shared page - there is the potential for an interrupt causing the process to be switched to a different CPU, resulting in an incorrect page being accessed. The shared page(s) can be in the form of an elf module that is linked with the process at load time. that way you can put cpu-specific code snippets there as well. when using a shared page to modify the TSC value read, one also needs to tempirarily lock the cpu you are on between the time you read the calibration value and the time you read the TSC.. A user process has only limited ability to do that. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
