Re: projects/armv6 merged to HEAD
On 22 Aug 2012, at 04:17, George Neville-Neil wrote: > > On Aug 17, 2012, at 05:24 , Robert Watson wrote: > >> >> On Thu, 16 Aug 2012, Oleksandr Tymoshenko wrote: >> >>> projects/armv6 branch was merged to HEAD and should be considered dead now. >>> This patch is a result of a joint effort by many people. Including but not >>> limited to: >> >> Amazing work -- many thanks are due to to everyone who was involved! >> > > And this ought to simplify work on both the Rasberry Pi and BeagleBone, as > well as the > rest of the arm systems. Great! What he said. Big thanks to all concerned! -- 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"
Re: projects/armv6 merged to HEAD
On Aug 17, 2012, at 05:24 , Robert Watson wrote: > > On Thu, 16 Aug 2012, Oleksandr Tymoshenko wrote: > >> projects/armv6 branch was merged to HEAD and should be considered dead now. >> This patch is a result of a joint effort by many people. Including but not >> limited to: > > Amazing work -- many thanks are due to to everyone who was involved! > And this ought to simplify work on both the Rasberry Pi and BeagleBone, as well as the rest of the arm systems. Great! Best, George ___ 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: projects/armv6 merged to HEAD
On Thu, 16 Aug 2012, Oleksandr Tymoshenko wrote: projects/armv6 branch was merged to HEAD and should be considered dead now. This patch is a result of a joint effort by many people. Including but not limited to: Amazing work -- many thanks are due to to everyone who was involved! Robert Grzegorz Bernacki (gber@) Aleksander Dutkowski Ben R. Gray (bgray@) Olivier Houchard (cognet@) Rafal Jaworowski (raj@) and Semihalf team Tim Kientzle (kientzle@) Jakub Wojciech Klama (jceel@) Ian Lepore Warner Losh (imp@) Damjan Marion (dmarion@) Lukasz Plachno Stanislav Sedov (stas@) Mark Tinguely Andrew Turner (andrew@) Thanks to all, who contributed by submitting code, testing and giving valuable advices. Code drop includes following parts: - General ARMv6/ARMv7 kernel bits (pmap, cache, assembler routines, etc...) - ARM SMP support - VFP/Neon support - ARM Generic Interrupt Controller driver - Improved thread-local storage for cpus >=ARMv6 - Two new values for TARGET_ARCH: armv6 and armv6eb - Driver for SMSC LAN95XX and LAN8710A ethernet controllers - Marvell MV78x60 support (multiuser, ARMADA XP kernel config) - TI OMAP4 and AM335x support (multiuser, no GPU or graphics support, kernel configs for Pandaboard and Beaglebone) - LPC32x0 support (multiuser, frame buffer works with SSD1289 LCD controller.Embedded Artists EA3250 kernel config) - Barebone Nvidia Tegra2 support (timers, interrupts and UART. No kernel config) Hope now that the code is in trunk it will get more attention and love from developers. Happy hacking -- gonzo ___ freebsd-a...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-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"
projects/armv6 merged to HEAD
Hello, projects/armv6 branch was merged to HEAD and should be considered dead now. This patch is a result of a joint effort by many people. Including but not limited to: Grzegorz Bernacki (gber@) Aleksander Dutkowski Ben R. Gray (bgray@) Olivier Houchard (cognet@) Rafal Jaworowski (raj@) and Semihalf team Tim Kientzle (kientzle@) Jakub Wojciech Klama (jceel@) Ian Lepore Warner Losh (imp@) Damjan Marion (dmarion@) Lukasz Plachno Stanislav Sedov (stas@) Mark Tinguely Andrew Turner (andrew@) Thanks to all, who contributed by submitting code, testing and giving valuable advices. Code drop includes following parts: - General ARMv6/ARMv7 kernel bits (pmap, cache, assembler routines, etc...) - ARM SMP support - VFP/Neon support - ARM Generic Interrupt Controller driver - Improved thread-local storage for cpus >=ARMv6 - Two new values for TARGET_ARCH: armv6 and armv6eb - Driver for SMSC LAN95XX and LAN8710A ethernet controllers - Marvell MV78x60 support (multiuser, ARMADA XP kernel config) - TI OMAP4 and AM335x support (multiuser, no GPU or graphics support, kernel configs for Pandaboard and Beaglebone) - LPC32x0 support (multiuser, frame buffer works with SSD1289 LCD controller.Embedded Artists EA3250 kernel config) - Barebone Nvidia Tegra2 support (timers, interrupts and UART. No kernel config) Hope now that the code is in trunk it will get more attention and love from developers. Happy hacking -- gonzo ___ 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: svn commit: r210561 - projects/sv/sys/net
On Thu, 2010-07-29 at 14:06 -0700, Ed Maste wrote: > On Wed, Jul 28, 2010 at 03:10:31PM +, Attilio Rao wrote: > > > Log: > > Initial import of the netdump files. > > They still need a lot of polishing and cleanup so they might not be > > considered definitive at all. > > This code is a port to recent FreeBSD of Darrell Anderson's network > crashdump support, which was done in the 4.x days. I can't find a > current website with the original versions but archive.org has a cache > of course: > > http://web.archive.org/web/20041204223729/http://www.cs.duke.edu/~anderson/freebsd/netdump/ > > Quoting from the old readme: > > Netdump provides FreeBSD kernel crash dumping over the network. > Netdump is a FreeBSD kernel module client and user-level server. > > A normal kernel crash writes a raw dump of memory to a dedicated > partition (usually the swap partition) using a low-level disk routine, > and then copies that raw dump into a file (via savecore) during the > following boot process. > > Netdump replaces the standard dump routine. During a crash, a netdump > client broadcasts to locate a netdump server, then sends the dump as > UDP/IP packets (with retransmission after loss). The netdump server > creates a dump file suitable for gdb. If netdump fails (for example, > no netdump server is located), a normal disk dump is performed. > > There is cleanup work to be done still, but we plan to have this in > shape for 9.0. > > -Ed > ___ Excellent. I'll start tracking this over here at Yahoo. 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: svn commit: r210561 - projects/sv/sys/net
On Wed, Jul 28, 2010 at 03:10:31PM +, Attilio Rao wrote: > Log: > Initial import of the netdump files. > They still need a lot of polishing and cleanup so they might not be > considered definitive at all. This code is a port to recent FreeBSD of Darrell Anderson's network crashdump support, which was done in the 4.x days. I can't find a current website with the original versions but archive.org has a cache of course: http://web.archive.org/web/20041204223729/http://www.cs.duke.edu/~anderson/freebsd/netdump/ Quoting from the old readme: Netdump provides FreeBSD kernel crash dumping over the network. Netdump is a FreeBSD kernel module client and user-level server. A normal kernel crash writes a raw dump of memory to a dedicated partition (usually the swap partition) using a low-level disk routine, and then copies that raw dump into a file (via savecore) during the following boot process. Netdump replaces the standard dump routine. During a crash, a netdump client broadcasts to locate a netdump server, then sends the dump as UDP/IP packets (with retransmission after loss). The netdump server creates a dump file suitable for gdb. If netdump fails (for example, no netdump server is located), a normal disk dump is performed. There is cleanup work to be done still, but we plan to have this in shape for 9.0. -Ed ___ 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 week projects
Sean Bruno skrev: My open source class this summer has a lot of people in it looking for 8 week projects. If you have a decently spec'd out project that a Junior/Senior CS student can accomplish, send me a link or pointer to it and I'll see if I can get the project some attention. There are many TODO lists on the wiki (some may be outdated): http://wiki.freebsd.org/Networking http://wiki.freebsd.org/IPv6TODO http://wiki.freebsd.org/BsnmpTODO http://wiki.freebsd.org/Jails http://wiki.freebsd.org/USBTODO http://wiki.freebsd.org/SMPTODO -- Joel ___ 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 week projects
On 24/6/09 17:40, Sean Bruno wrote: > My open source class this summer has a lot of people in it looking for 8 > week projects. > > If you have a decently spec'd out project that a Junior/Senior CS > student can accomplish, send me a link or pointer to it and I'll see if > I can get the project some attention. > > Dont know about decently spec'd but http://www.freebsd.org/projects/ideas/ has a bunch of ideas if thats any help. Vince > 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" > ___ 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"
8 week projects
My open source class this summer has a lot of people in it looking for 8 week projects. If you have a decently spec'd out project that a Junior/Senior CS student can accomplish, send me a link or pointer to it and I'll see if I can get the project some attention. 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: cvs commit: www/en/projects/ideas index.sgml
Quoting Robert Watson <[EMAIL PROTECTED]> (from Fri, 28 Jul 2006 13:45:50 +0100 (BST)): On Fri, 28 Jul 2006, Alexander Leidinger wrote: BTW, a problem that has occurred a number of times in the past is that people have approached us with implementations of ideas in the idea list that it has later transpired we aren't actually interested in (sometimes at all). I think it might not be a bad idea to sprinkle the My impression is, that we lack some committers which not only have time to review the submissions, but also have the necessary domain specific knowledge at the same time. I suggest marking unreviewed ideas as unreviewed then. My biggest Which isn't entirely true. We filter incoming ideas (we at least rejected one or two... after talking with the submitter), but we aren't able to distinguish good looking but bad ideas from good looking and good ideas. Some ideas are only rejectable by someone with enough domain specific knowledge and look ok for most other people. So when do you think an entry is reviewed? How to determine whom to ask for review and how to get this person interested enough for a review? concern is that we have people who come along, see the idea, implement it, and it's then dropped on the floor because it turns out we didn't really want it, but it was on the list. If we don't want it, we shouldn't list it. If we're not sure if we want it, but think it might be neat, then we should say that's why it's on the list, so as to avoid misunderstandings. I agree. We need some reviewers here... while I'm able to come up with a nice technical description of roughly expressed ideas (as long as I get the idea), I'm not a TRB and as such aren't aware of every implication. And some ideas are expressed in a way which make them sound like it's "common knowledge to people which work in this field" (ATM I refer to the NFS lockd in kernel implementation idea). Given that we can't get the user space code to work and don't have an owner for it (it appears to be abandonware), I think moving it into the kernel would be a disaster. Uhm... I'm withhin the implicit assumption that we first need to fix NFS lockd (an entry before the "move into the kernel" entry)... ok, we need to record dependencies here. So: helping hands are welcome! Thanks for taking some time to review some parts of the list. I'll try to take a look through the rest of them later today. Thanks, Alexander. -- Let me put it this way: today is going to be a learning experience. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: www/en/projects/ideas index.sgml
Quoting Robert Watson <[EMAIL PROTECTED]> (from Fri, 28 Jul 2006 09:52:33 +0100 (BST)): [moving to [EMAIL PROTECTED] feel free to redirect if you think there's a more appropriate list] On Fri, 28 Jul 2006, Joel Dahl wrote: Modified files: en/projects/ideasindex.sgml Log: - Extend the ktrace project with a new task. [1] [adding some warnings to this project] Thanks for reviewing and the heads up regarding problems which may arise. Yes, we should add them to the entry. BTW, a problem that has occurred a number of times in the past is that people have approached us with implementations of ideas in the idea list that it has later transpired we aren't actually interested in (sometimes at all). I think it might not be a bad idea to sprinkle the My impression is, that we lack some committers which not only have time to review the submissions, but also have the necessary domain specific knowledge at the same time. idea list with some additional cautionary language -- often ideas listed there are things to explore, not to adopt without very careful consideration. For example, the "FPU subsystem overhaul", "Process Uhm... the FPU one... ok. AFAIK bde reviewed it. I haven't seen the review (or I don't remember it), but so far it looks like it would be beneficial to commit it (AFAIR). I'm not able to review the code (I lack the necessary domain specific knowledge), but I wanted to give it a try on my system and then send a mail to arch to get some technical reasons why to not commit commit it. Similar for the new TCP checksumming code. Initially there was a problem, it got fixed, and now nobody takes care of it since everyone seems to think "it's flawed". At least this is the impression I got. checkpointing", "Pluggable disk shceduler", "Magic Symlinks", "NFS Lockd (kernel implementation)", and several others -- the task here often isn't to port/write the code, the task is to port/write and then perform a detailed and careful evaluation of the changes to decide whether they are a good idea, and then consider adopting the code only if the evaluation suggests it is a good idea and after significant refinment. So far we got not much responses from committers/developers. There's a lot of interest in working on some of the entries, but so far we don't get much review for the entries/ideas themself. Any refinement is welcome and appreciated. So if someone has some thoughts about specific entries: please, share them with us. Some of the ideas on this list are distinctly "explore this direction as a computer scientist, not a code hacker" sorts of problems -- for example, the "Process checkpointing" task seems to suggest that if you can read the DFBSD repository and write some C code, you're set. In fact, this is not remotely the case. Checkpointing is a very difficult problem in computer science, with little consensus on how it should be done (and indeed whether it should be done at all) by general purpose operating systems. Not only that, but we would not adopt the DFBSD implementation as-is, as it solves a few of the easy problems, and none of the hard ones (i.e., security). The requirements here aren't just the ability to write code, but an understanding of distributed systems, our application/execution model, a strong understanding of the performance and security requirements, and willingness to not just look at code but the extensive research literature on this topic. AFAIR the process checkpointing in DFly has to be enabled (or am I mixing this up with the magic symlinks?) in the kernel. And the man page contains some text what is possible and what not, and about security implications. Yes, they don't use a model which is able to solve all cases, but for some cases where the programs (those which don't make heavy use of I/O and thus can open/close I/O channels when they are needed) are written to make use of this feature, you can make some users happy and the developers can concentrate at the problem at hand. So it's one of those 80/20 solutions. While I agree that a 100% solution would be nice, I think an implementation of this in -current would be nice to have. I think people often grab ideas from the list thinking that if implemented as described, they will get committed, and this is not the case. In many of the sorts of "scientific" cases it's likely we'll look at the results and say, "Oh, that was a bad idea", or maybe slightly more likely, "Oh, hmm, not so sure about that". The existing Joel and I already talked briefly about an "we don't do that" or "been there, done that, wasn't a good idea" page because of this. cautionary language captures that there might be disagreements on t
Re: cvs commit: www/en/projects/ideas index.sgml
On Fri, 28 Jul 2006, Alexander Leidinger wrote: BTW, a problem that has occurred a number of times in the past is that people have approached us with implementations of ideas in the idea list that it has later transpired we aren't actually interested in (sometimes at all). I think it might not be a bad idea to sprinkle the My impression is, that we lack some committers which not only have time to review the submissions, but also have the necessary domain specific knowledge at the same time. I suggest marking unreviewed ideas as unreviewed then. My biggest concern is that we have people who come along, see the idea, implement it, and it's then dropped on the floor because it turns out we didn't really want it, but it was on the list. If we don't want it, we shouldn't list it. If we're not sure if we want it, but think it might be neat, then we should say that's why it's on the list, so as to avoid misunderstandings. idea list with some additional cautionary language -- often ideas listed there are things to explore, not to adopt without very careful consideration. For example, the "FPU subsystem overhaul", "Process Uhm... the FPU one... ok. AFAIK bde reviewed it. I haven't seen the review (or I don't remember it), but so far it looks like it would be beneficial to commit it (AFAIR). I'm not able to review the code (I lack the necessary domain specific knowledge), but I wanted to give it a try on my system and then send a mail to arch to get some technical reasons why to not commit commit it. Similar for the new TCP checksumming code. Initially there was a problem, it got fixed, and now nobody takes care of it since everyone seems to think "it's flawed". At least this is the impression I got. I have no specific technical opinion on either of these items. Some of the ideas on this list are distinctly "explore this direction as a computer scientist, not a code hacker" sorts of problems -- for example, the "Process checkpointing" task seems to suggest that if you can read the DFBSD repository and write some C code, you're set. In fact, this is not remotely the case. Checkpointing is a very difficult problem in computer science, with little consensus on how it should be done (and indeed whether it should be done at all) by general purpose operating systems. Not only that, but we would not adopt the DFBSD implementation as-is, as it solves a few of the easy problems, and none of the hard ones (i.e., security). The requirements here aren't just the ability to write code, but an understanding of distributed systems, our application/execution model, a strong understanding of the performance and security requirements, and willingness to not just look at code but the extensive research literature on this topic. AFAIR the process checkpointing in DFly has to be enabled (or am I mixing this up with the magic symlinks?) in the kernel. And the man page contains some text what is possible and what not, and about security implications. Yes, they don't use a model which is able to solve all cases, but for some cases where the programs (those which don't make heavy use of I/O and thus can open/close I/O channels when they are needed) are written to make use of this feature, you can make some users happy and the developers can concentrate at the problem at hand. So it's one of those 80/20 solutions. While I agree that a 100% solution would be nice, I think an implementation of this in -current would be nice to have. It's a neat/fun hack, but I would object strongly to the current implementation going into the tree. I think 80/20 is a mischaracterization. We need some reviewers here... while I'm able to come up with a nice technical description of roughly expressed ideas (as long as I get the idea), I'm not a TRB and as such aren't aware of every implication. And some ideas are expressed in a way which make them sound like it's "common knowledge to people which work in this field" (ATM I refer to the NFS lockd in kernel implementation idea). Given that we can't get the user space code to work and don't have an owner for it (it appears to be abandonware), I think moving it into the kernel would be a disaster. We've been discussing ripping out the current user space code entirely on the basis that it is responsible for a huge number of bug reports and lots of problems. So: helping hands are welcome! Thanks for taking some time to review some parts of the list. I'll try to take a look through the rest of them later today. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OpenSolaris emulation? (was Re: FreeBSD list of projects for volunteers)
On Thu, Dec 08, 2005 at 06:12:42PM +0100, [EMAIL PROTECTED] wrote: > (sorry for cross-posting, in the future this seems better suited for > emulation@ > ) > > Hi; > > I didn't see any interest for this on the website but perhaps we should be > working on improving our SVR4 emulation now that OpenSolaris is available. > Possible tasks include: > > - Updating the emulator wrt NetBSD. > - Packaging OpenSolaris binary libraries: it seems like the license might > require us setting some of it as RESTRICTED though. > - General testing on sparc64, i386 or amd64 platforms. > - Porting ZFS would be great ;-). Sounds great, keep us informed! Kris pgp0s0aQuHkhg.pgp Description: PGP signature
OpenSolaris emulation? (was Re: FreeBSD list of projects for volunteers)
(sorry for cross-posting, in the future this seems better suited for emulation@ ) Hi; I didn't see any interest for this on the website but perhaps we should be working on improving our SVR4 emulation now that OpenSolaris is available. Possible tasks include: - Updating the emulator wrt NetBSD. - Packaging OpenSolaris binary libraries: it seems like the license might require us setting some of it as RESTRICTED though. - General testing on sparc64, i386 or amd64 platforms. - Porting ZFS would be great ;-). Pedro ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD list of projects for volunteers
Hi all, As some of you may have noticed, we've added a new section to the website, which contains a lot of interesting projects and ideas that volunteers and developers are encouraged to evaluate and work on. Some of these projects are simple, and someone just needs to spend some time on them and do the work, some are harder, intended for junior kernel hackers. This should also serve as a good starting point for people that would like to contribute to FreeBSD and perhaps become committers in the future. You can find the list here: http://www.freebsd.org/projects/ideas/ -- Joel - joel at FreeBSD dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Are there any on-going projects on v4l porting?
Performance is important, but I'd call having good design even more important, righteous API included. Having (potential) application developers mess with ioctl's and such doesn't seem good to me. Now, to not to reimplement the wheel, I'd repeat the suggestion of basically copying and adapting something for start. Further details should be kept off this list, I think, perhaps in [-multimedia]. Harti Brandt wrote: On Wed, 12 Mar 2003, Dan Nelson wrote: DN>In the last episode (Mar 12), Yury Tarasievich said: DN>> At http://freebsddvb.narod.ru, there exists an adequately up-to-date DN>> port of linux DVB drivers, seemingly supporting DVB adapters up to DN>> rev.1.5. DN>> DN>> Regarding porting of V4L. I may be utterly wrong, but isn't the whole DN>> V4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed? DN>> Could something reincarnating BeOS (or even OS/2) multimedia DN>> subsystem be better? DN> DN>I like the idea of putting this into the Xfree86 drivers and using the DN>XVideo extension to drive everything. that doesn't require kernel DN>mods. It does mean that you need to start X up to capture video, DN>though. The problem with this is probably the number of context switches and copies or IPC you need to get a frame. With > 25 fps this is a problem. harti To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Are there any on-going projects on v4l porting?
On Wed, 12 Mar 2003, Dan Nelson wrote: DN>In the last episode (Mar 12), Yury Tarasievich said: DN>> At http://freebsddvb.narod.ru, there exists an adequately up-to-date DN>> port of linux DVB drivers, seemingly supporting DVB adapters up to DN>> rev.1.5. DN>> DN>> Regarding porting of V4L. I may be utterly wrong, but isn't the whole DN>> V4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed? DN>> Could something reincarnating BeOS (or even OS/2) multimedia DN>> subsystem be better? DN> DN>I like the idea of putting this into the Xfree86 drivers and using the DN>XVideo extension to drive everything. that doesn't require kernel DN>mods. It does mean that you need to start X up to capture video, DN>though. The problem with this is probably the number of context switches and copies or IPC you need to get a frame. With > 25 fps this is a problem. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Are there any on-going projects on v4l porting?
On Wed, 12 Mar 2003, Yury Tarasievich wrote: YT>At http://freebsddvb.narod.ru, there exists an adequately up-to-date YT>port of linux DVB drivers, seemingly supporting DVB adapters up to rev.1.5. YT> YT>Regarding porting of V4L. I may be utterly wrong, but isn't the whole YT>V4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed? YT>Could something reincarnating BeOS (or even OS/2) multimedia subsystem YT>be better? Yes, last time I had a look at V4L2 it was utterly broken with regard to ingeneering. Using a O_ flag to the open call to tell the system that you are going to use only ioctl()s and stuff like that... harti To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Are there any on-going projects on v4l porting?
In the last episode (Mar 12), Yury Tarasievich said: > At http://freebsddvb.narod.ru, there exists an adequately up-to-date > port of linux DVB drivers, seemingly supporting DVB adapters up to > rev.1.5. > > Regarding porting of V4L. I may be utterly wrong, but isn't the whole > V4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed? > Could something reincarnating BeOS (or even OS/2) multimedia > subsystem be better? I like the idea of putting this into the Xfree86 drivers and using the XVideo extension to drive everything. that doesn't require kernel mods. It does mean that you need to start X up to capture video, though. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Are there any on-going projects on v4l porting?
At http://freebsddvb.narod.ru, there exists an adequately up-to-date port of linux DVB drivers, seemingly supporting DVB adapters up to rev.1.5. Regarding porting of V4L. I may be utterly wrong, but isn't the whole V4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed? Could something reincarnating BeOS (or even OS/2) multimedia subsystem be better? Vladimir Kushnir wrote: As subj. said - does anybody work on porting v4l & (especially!) drivers for non- bt8x based cards? Specifically saa7134 based (got one and would rather not have to reboot to Linux to watch TV :-) Yes, I know, the simplest answer would be "you're interested - you do" but that'd be quite beyond my skills. Still I'd happily help with testing/debugging/whatever else. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Are there any on-going projects on v4l porting?
Hello all, As subj. said - does anybody work on porting v4l & (especially!) drivers for non- bt8x based cards? Specifically saa7134 based (got one and would rather not have to reboot to Linux to watch TV :-) Yes, I know, the simplest answer would be "you're interested - you do" but that'd be quite beyond my skills. Still I'd happily help with testing/debugging/whatever else. Regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some small projects for mutt(1)
On Thu, Jun 20, 2002 at 04:18:38PM -0400, Bosko Milekic wrote: > > > Interesting. How would you have a key bound sequence in mutt set off > the script on the message, though? For instance, if I do a "ctrl+B", how > would you ensure that the Right Thing happens, without modifying mutt > code? > Like this: # Urlview macro index \cv |urlview\n macro pager \cv |urlview\n # Hot keys macro index \cn l~N\n macro index \ca lall\n That fragment from my .muttrc says that control-v is used to invoke the script urlview (which is in the ports and produces a list of urls in the email message, and allows me to selection one which gets piped to a browser). I've also go ctrl-N and ctrl-A set for each message selection. Joe msg35408/pgp0.pgp Description: PGP signature
Re: projects?
On Sat, Jun 22, 2002 at 01:03:34AM +0200, Mark Santcroos wrote: > On Fri, Jun 21, 2002 at 11:04:36AM -0700, Brooks Davis wrote: > > For my purposes, it would need to be seperate so you could copy the > > module and hack in a new TCP without changing the existing one. > > I understand, but you won't need to do that for the IP layer in your case. > Other people might have a reverse situation, so some hooks to both these > layers would come in handy, that was my point. It depends on what you're trying to do. If all you want to do is mess with in-kernel TCP implementations then just hooking into the existing IP layer is sufficent. I'm also thinking that the ability to run netgraph code in a hybrid userland/kernel environment for development would be useful in which case it would be useful to be able to implement the whole network stack in netgraph nodes. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35179/pgp0.pgp Description: PGP signature
Re: projects?
On Fri, Jun 21, 2002 at 11:04:36AM -0700, Brooks Davis wrote: > For my purposes, it would need to be seperate so you could copy the > module and hack in a new TCP without changing the existing one. I understand, but you won't need to do that for the IP layer in your case. Other people might have a reverse situation, so some hooks to both these layers would come in handy, that was my point. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects?
Julian Elischer wrote: > On Thu, 20 Jun 2002, Terry Lambert wrote: > > Basically, that's my short list. There are actually a lot more > > things that could be done in the networking area; there are things > > to do in the routing area, and things to do with RED queueing, and > > things to do with resource tuning, etc., and, of course, there's > > the bugs that you normally see in the BSD stack only when you try > > to dothings like open more than 65535 outbound connections from a > > single box, etc.. > > > > Personally, I'm tired of solving the same problems over and over > > again, so I'd like to see the code in FreeBSD proper, so that it > > becomes part of the intellectual commons. > > > > SO which project are you going to do terry? I don't know, Julian... for which one will you give me a Masters degree from an accredited University? This thread is still about students looking for a projects. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects?
On Fri, Jun 21, 2002 at 08:37:15AM +0200, Mark Santcroos wrote: > On Thu, Jun 20, 2002 at 01:21:30PM -0700, Julian Elischer wrote: > > I've been considereing this as a fun project. The difficult comes at the > > interface/IP boundary.. we'd need am ng_route node to multiplex > > the packets to the correct output nodes... > > Would it be needed to duplicate the whole stack in the netgraph node or > would it be relatively easy to hook it up to the existing ip and tcp code? For my purposes, it would need to be seperate so you could copy the module and hack in a new TCP without changing the existing one. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35162/pgp0.pgp Description: PGP signature
Re: projects?
On Fri, 21 Jun 2002, Mark Santcroos wrote: > On Thu, Jun 20, 2002 at 01:21:30PM -0700, Julian Elischer wrote: > > I've been considereing this as a fun project. The difficult comes at the > > interface/IP boundary.. we'd need am ng_route node to multiplex > > the packets to the correct output nodes... > > Would it be needed to duplicate the whole stack in the netgraph node or > would it be relatively easy to hook it up to the existing ip and tcp code? > I'd try start with a second copy of the existing code and see what needs to be hacked.. If it were easy enough you could retrofit th changes to th current code but I suspect that it woudl diverge... > Just wondering. > > Mark > > -- > Mark SantcroosRIPE Network Coordination Centre > http://www.ripe.net/home/mark/New Projects Group/TTM > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects?
On Thu, 20 Jun 2002, Terry Lambert wrote: > > Basically, that's my short list. There are actually a lot more > things that could be done in the networking area; there are things > to do in the routing area, and things to do with RED queueing, and > things to do with resource tuning, etc., and, of course, there's > the bugs that you normally see in the BSD stack only when you try > to dothings like open more than 65535 outbound connections from a > single box, etc.. > > Personally, I'm tired of solving the same problems over and over > again, so I'd like to see the code in FreeBSD proper, so that it > becomes part of the intellectual commons. > SO which project are you going to do terry? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects?
On Thu, Jun 20, 2002 at 01:21:30PM -0700, Julian Elischer wrote: > I've been considereing this as a fun project. The difficult comes at the > interface/IP boundary.. we'd need am ng_route node to multiplex > the packets to the correct output nodes... Would it be needed to duplicate the whole stack in the netgraph node or would it be relatively easy to hook it up to the existing ip and tcp code? Just wondering. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects?
Great list, thanks for that. While I think LRP and TCP Rate Halving are quite interesting, I think tackling the SMP Safe Queues makes the best use my resources. I fear that testing some of the other items requires setups that are not feasible for me. Cheers, Aram Terry Lambert wrote: Aram Compeau wrote: Too bad he's sick of networking. There a lot of intersting codethat could be implemented in the main line FreeBSD that would bereally beneficial, overall. Could you elaborate briefly on what you'd like to see worked on withrespect to this? I don't want you to spend a lot of time describinganything, but I am curious. I don't generally have large blocks of sparetime, but could work on something steadily with a low flame. ---LRP---I would like FreeBSD to support LRP (Lazy Receiver Processing),an idea which came from the Scala Server Project at RiceUniversity.LRP gets rid of the need to run network processing in kernelthreads, in order to get parallel operation on SMP systems;so long as the interrupt processing load is balanced, it'spossible to handle interrupts in an overlapped fashion.Right now, there are four sets of source code: SunOS 4.1.3_U1,FreeBSD 2.2-BETA, FreeBSD 4.0, FreeBSD 4.3. The first threeare from Rice University. The fourth is from Duke University,and is a port forward of the 4.0 Rice code.The Rice code, other than the FreeBSD 2.2-BETA, is unusable.It mixes in an idea called "Resource Containers" (RESCON),that is really not very useful (I can go into great detail onthis, if necessary). It also has a restrictive license. TheFreeBSD 2.2-BETA implementation h as a CMU MACH style license(same as some FreeBSD code already has).The LRP implementation in all these cases is flawed, in thatit assumes that the LRP processing will be universal acrossan entire address family, and the experimental implementationloads a full copy of the AF_INET stack under another familyname. A real integration is tricky, including credentials onaccept calls, an attribute on the family struct, to indicatethat it's LRP'ed, so that common subsystems can behave verydifferently, support for Accept filters and othe Kevents, etc.).LRP gives a minimum of a factor of 3 improvement in connectionsper second, without the SYN cache code involved at all, throughan overall reduction in processing latency. It also has theeffect of preventing "receiver livelock". http://www.cs.rice.edu/CS/Systems/LRP/ http://www.cs.duke.edu/~anderson/freebsd/muse-sosp/readme.txtTCP Rate HalvingI would like to see FreeBSD support TCP Rate Halving, and ideafrom the Pittsburgh Cupercomputing Center (PSC) at CarengieMellon University (CMU).These are the people who invented "traceroute".TCP Rate halving is an alternative to the RFC-2581 Fast Recoveryalgorithm for congestion control. It effectively causes thecongestion recovery to be self-clocked by ACKs, which has theoverall effect of avoiding the normal burstiness of TCP recoveryfollowing congestion.This builds on work by Van Jacobsen, J. Hoe, and Sally Floyd.Their current implementation is for NetBSD 1.3.2. http://www.psc.edu/networking/rate_halving.h tml---SACK, FACK, ECN---Also from PSC at CMU.SACK and FACK are well known. It's annnoying that Luigi Rizzo'scode from 1997 or so was never integrated into FreeBSD.ECN is an implementation of Early Congestion Notification. http://www.psc.edu/networking/tcp.htmlVRRPThere is an implementation of a real VRRP for FreeBSD available;it is in ports.This is a real VRRP (Virtual Router Redundancy Protocol), notlike the Linux version which uses the multicast mask and thusloses multicast capability.There are intersting issues in actual deployment of this code;specifically, the VMAC that needs to be used in order tologically seperate virtual routers is not really implementedwell, so there are common ARP issues.There are a couple of projects that one could take on here; byfar, the most interesting (IMO) would be to support multiplevirtual network cards on a single physical network card. Mostof the Gigabit Ethernet cards, and some of the 10/100Mbit cards,can support multiple MAC addresses (the Intel Gigabit card cansupport 16, the Tigon III supports 4, and the Tigone II supports2).The work required would be to support the ability to have asingle driver, single NIC, multiple virtual NICs.There are also interesting issues, like being able to selectivelycontrol ARP response from a VRRP interface which is not themaster interface. This has intersting implications for therouting code, and for the initialization code, which normallyhandles the gratuitous ARP. More information can be found inthe VRRP RFC, RFC-2338.--TCP Timers--I've discussed this before in depth. Basically, the timer codeis very poor for a large nu mber of connections, and increasingthe size o
Re: projects?
On Thu, 20 Jun 2002, Brooks Davis wrote: > On Wed, Jun 19, 2002 at 10:09:07PM -0400, David E. Cross wrote: > > He is however "quite sick" of networking, and was originally looking at > > the VM code as a potential area (he is gaining an interest in > > parallelization and synchronization). > > Something I'd like to see which is unfortunatly network releated is ng_ip, > ng_tcp, and ng_udp netgraph modules. Since the networking code already > exists (though it's probably got a number of layering violations in it > that would need to be sorted out) this would be more of an infrastructure > project then a networking project. It would have things to measure > (comparative throughput and latency, for example.) If these modules > were available, netgraph would become much more intresting as a basis > for network research (say building distributed simulators). Later > researchers could add ng_tcp_reno, ng_tcp_vegas, or even ng_tca_daytona > (the messed up "accelerated" tcp which acks each byte seperatly.) I've been considereing this as a fun project. The difficult comes at the interface/IP boundary.. we'd need am ng_route node to multiplex the packets to the correct output nodes... :-) > > -- Brooks > > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some small projects for mutt(1)
On Thu, 20 Jun 2002, Bosko Milekic wrote: > Hey, this is awesome stuff! Thanks! How come we don't have a port? I've been busy. ;-) Feel free to do the port if you get time before I do. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[>++<-]>[<++>-]<.>[>+<-]>[<+>-]<+.+++..++ +.>>+[<++>-]<++.<<+++.>.+++.--..>+. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some small projects for mutt(1)
On Thu, Jun 20, 2002 at 03:27:24PM -0500, Brandon D. Valentine wrote: > On Thu, 20 Jun 2002, Bosko Milekic wrote: > > >On Thu, Jun 20, 2002 at 01:10:39PM -0700, Matthew Hunt wrote: > >> This shouldn't be hard to glue together without modifying mutt itself. > >> Make a little program, foo, that takes the message on stdin, passes > >> it through "formail -x subject", massages it into a procmail rule, and > >> appends it to some procmail rule file. The "massage" step should include > >> escaping characters that have special meanings in procmail regexps, and > >> adding something like (Re: *)? at the beginning of the subject when > >> appropriate. Shouldn't be more than a screenful of Perl. > > > > Interesting. How would you have a key bound sequence in mutt set off > >the script on the message, though? For instance, if I do a "ctrl+B", how > >would you ensure that the Right Thing happens, without modifying mutt > >code? > > Check out mutt2procmailrc written by my good friend timball: > > http://www.ghettohack.net/timball/ Hey, this is awesome stuff! Thanks! How come we don't have a port? > It rocks. > > Brandon D. Valentine > -- > http://www.geekpunk.net [EMAIL PROTECTED] > ++[>++<-]>[<++>-]<.>[>+<-]>[<+>-]<+.+++..++ > +.>>+[<++>-]<++.<<+++.>.+++.--..>+. Regards, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some small projects for mutt(1)
On Thu, Jun 20, 2002 at 04:18:38PM -0400, Bosko Milekic wrote: > Interesting. How would you have a key bound sequence in mutt set off > the script on the message, though? For instance, if I do a "ctrl+B", how > would you ensure that the Right Thing happens, without modifying mutt > code? By adding something like this to your .muttrc: macro index \Cb '|/usr/local/bin/junkmail^M' -- Matthew Hunt <[EMAIL PROTECTED]> * Science rules. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some small projects for mutt(1)
On Thu, 20 Jun 2002, Bosko Milekic wrote: >On Thu, Jun 20, 2002 at 01:10:39PM -0700, Matthew Hunt wrote: >> This shouldn't be hard to glue together without modifying mutt itself. >> Make a little program, foo, that takes the message on stdin, passes >> it through "formail -x subject", massages it into a procmail rule, and >> appends it to some procmail rule file. The "massage" step should include >> escaping characters that have special meanings in procmail regexps, and >> adding something like (Re: *)? at the beginning of the subject when >> appropriate. Shouldn't be more than a screenful of Perl. > > Interesting. How would you have a key bound sequence in mutt set off >the script on the message, though? For instance, if I do a "ctrl+B", how >would you ensure that the Right Thing happens, without modifying mutt >code? Check out mutt2procmailrc written by my good friend timball: http://www.ghettohack.net/timball/ It rocks. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[>++<-]>[<++>-]<.>[>+<-]>[<+>-]<+.+++..++ +.>>+[<++>-]<++.<<+++.>.+++.--..>+. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some small projects for mutt(1)
On Thu, Jun 20, 2002 at 01:10:39PM -0700, Matthew Hunt wrote: > On Thu, Jun 20, 2002 at 03:24:54PM -0400, Bosko Milekic wrote: > > > cool if mutt did it). What this does is pretty straightforward: I see > > a thread with subject "foo." I don't like it. I really don't like it. > > I hit a key combination such as, I don't know, CTRL+B (or something not > > bound yet), and not only is the entire thread instantly marked for > > deletion, but a carefully crafted rule is also dropped into a sh*tlist > > file (that can be handled by procmail?) which will ensure that all > > _future_ mailings that are in response to said thread will immediately > > be marked for deletion, or merely filtered. Hence, "persistent thread > > suppression/deletion." > > This shouldn't be hard to glue together without modifying mutt itself. > Make a little program, foo, that takes the message on stdin, passes > it through "formail -x subject", massages it into a procmail rule, and > appends it to some procmail rule file. The "massage" step should include > escaping characters that have special meanings in procmail regexps, and > adding something like (Re: *)? at the beginning of the subject when > appropriate. Shouldn't be more than a screenful of Perl. Interesting. How would you have a key bound sequence in mutt set off the script on the message, though? For instance, if I do a "ctrl+B", how would you ensure that the Right Thing happens, without modifying mutt code? > -- > Matthew Hunt <[EMAIL PROTECTED]> * Stay close to the Vorlon. > http://www.pobox.com/~mph/ * -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some small projects for mutt(1)
On Thu, Jun 20, 2002 at 03:24:54PM -0400, Bosko Milekic wrote: > cool if mutt did it). What this does is pretty straightforward: I see > a thread with subject "foo." I don't like it. I really don't like it. > I hit a key combination such as, I don't know, CTRL+B (or something not > bound yet), and not only is the entire thread instantly marked for > deletion, but a carefully crafted rule is also dropped into a sh*tlist > file (that can be handled by procmail?) which will ensure that all > _future_ mailings that are in response to said thread will immediately > be marked for deletion, or merely filtered. Hence, "persistent thread > suppression/deletion." This shouldn't be hard to glue together without modifying mutt itself. Make a little program, foo, that takes the message on stdin, passes it through "formail -x subject", massages it into a procmail rule, and appends it to some procmail rule file. The "massage" step should include escaping characters that have special meanings in procmail regexps, and adding something like (Re: *)? at the beginning of the subject when appropriate. Shouldn't be more than a screenful of Perl. -- Matthew Hunt <[EMAIL PROTECTED]> * Stay close to the Vorlon. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some small projects for mutt(1)
On Thu, Jun 20, 2002 at 02:36:41PM -0500, Sean Kelly wrote: > On Thu, Jun 20, 2002 at 03:24:54PM -0400, Bosko Milekic wrote: > > > > Hi, > > > > Two ideas have come up recently to extend the features of the mutt(1) > > Email client. I'm not one who has hacked on mutt, nor who really > > intends to (if I can avoid it, I will), so hence the reason for this > > post. > > It might just be me, but I don't see how the mutt e-mail client falls in > the scope of freebsd-hackers. Perhaps you should bring this up with the > mutt mailing lists? O, riiight. Sorry about that; we deffinately should go back to discussing only what's in the scope of freebsd-hackers, as you say; so back to your regularly scheduled flame wars! > -- > Sean Kelly | PGP KeyID: 77042C7B > [EMAIL PROTECTED] | http://www.zombie.org -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some small projects for mutt(1)
On Thu, Jun 20, 2002 at 03:24:54PM -0400, Bosko Milekic wrote: > > Hi, > > Two ideas have come up recently to extend the features of the mutt(1) > Email client. I'm not one who has hacked on mutt, nor who really > intends to (if I can avoid it, I will), so hence the reason for this > post. It might just be me, but I don't see how the mutt e-mail client falls in the scope of freebsd-hackers. Perhaps you should bring this up with the mutt mailing lists? -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Some small projects for mutt(1)
Hi, Two ideas have come up recently to extend the features of the mutt(1) Email client. I'm not one who has hacked on mutt, nor who really intends to (if I can avoid it, I will), so hence the reason for this post. So this post is directed at those people who have some extra time on their hands and are looking to make some sort of contribution to FreeBSD, but aren't prepared (or don't want to) muck in the kernel source. 1) The first feature is a persistent-thread-delete. This idea was given by Jonathan Mini at Usenix. I'm not aware of any client that supports this right now, but such a client may exist (in any case, it would be cool if mutt did it). What this does is pretty straightforward: I see a thread with subject "foo." I don't like it. I really don't like it. I hit a key combination such as, I don't know, CTRL+B (or something not bound yet), and not only is the entire thread instantly marked for deletion, but a carefully crafted rule is also dropped into a sh*tlist file (that can be handled by procmail?) which will ensure that all _future_ mailings that are in response to said thread will immediately be marked for deletion, or merely filtered. Hence, "persistent thread suppression/deletion." 2) An optional feature that would, when you hit 'y' to send that Email off, attempt to roughly analyze your message and present an "Are you sure you want to send this Email, it contains potentially inflammatory content?" confirmation request, based on the content of the message. I believe Eudora Lite has this sort of thing where if you key in something that looks offensive/like a flame, it will generate a popup with a warning like "Warning: this Email may offend the average reader, are you sure you went to send it?" I think this would help some of us out with controlling our tempers. If you want to make this extra cool, you could have a system where Email can be classified as "INFLAMMATORY" and "REALLY INFLAMMATORY," and the "REALLY INFLAMMATORY" Email would not only generate the warning, but would also set off a timer and only blast the Email away in N minutes, unless it is cancelled prior to the blastoff time. Anyway, I really think that (1) would be extremely useful. As for (2), well, it's kind of funny. :-) Cheers, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects?
On Wed, Jun 19, 2002 at 10:09:07PM -0400, David E. Cross wrote: > He is however "quite sick" of networking, and was originally looking at > the VM code as a potential area (he is gaining an interest in > parallelization and synchronization). Something I'd like to see which is unfortunatly network releated is ng_ip, ng_tcp, and ng_udp netgraph modules. Since the networking code already exists (though it's probably got a number of layering violations in it that would need to be sorted out) this would be more of an infrastructure project then a networking project. It would have things to measure (comparative throughput and latency, for example.) If these modules were available, netgraph would become much more intresting as a basis for network research (say building distributed simulators). Later researchers could add ng_tcp_reno, ng_tcp_vegas, or even ng_tca_daytona (the messed up "accelerated" tcp which acks each byte seperatly.) -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35085/pgp0.pgp Description: PGP signature
Re: projects that need to be done...
Trish Lynch wrote: > Question: > > what types of things can be done by people who are generally just > learning thier way around some of the code? is there anyone willing to > patiently work with a fast learner (yes, honestly my biggest fear is since > that I'm entirely self taught is that I have some bad habits, and someone > must be willing to LART me at every opportunity on them until I learn) The easiest approach that a lot of people have taken (I heard the statistic that the majority of people with commit bits today had their start this way) is to start documenting anything you don't find self explanatory. In the process, you will learn a lot about it, and at the same time, you will machete some of the jungle to make a path for the people who will follow. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects that need to be done...
On Thu, 6 Jun 2002, Mike Silbersack wrote: > > Or, if you're so inclined, start working on adding a feature that you find > lacking in FreeBSD. Mentoring someone is a great idea, but it doesn't end > up working too well in a volunteer project. Contribution works best when > it's self motivated. > > If you can't think of anything to do, Andrew's suggestion of looking > through the PR database is a good one. > > Mike "Silby" Silbersack > Yeah, I was just hoping someone wouldn;t mind it, since I either work better with one person's input, having a type of high functioning autism, I have a difficult time trying to make sense out of 30 different people's 30 different ways of doing something, I was trying to find someone who wouldn;t mind trying to clone themselves in a sense. -Trish -- Trish Lynch [EMAIL PROTECTED] FreeBSD The Power to Serve Ecartis Core Team [EMAIL PROTECTED] http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects that need to be done...
On Fri, 7 Jun 2002, Andrew wrote: > On Thu, 6 Jun 2002, Trish Lynch wrote: > > > what types of things can be done by people who are generally just > > learning thier way around some of the code? is there anyone willing to > > You could go through the PR database and see if there are any problems > reported that you could solve. If you can't actually solve it it doesn't > matter...you're further analysis may be enough to help someone else fix > it...you could post your results to the mailing list...i.e I was looking > at PR x and I found this, this and this. I think the problem is line x > in x.c but I'm not sure what the correct solution is... > > Andrew Or, if you're so inclined, start working on adding a feature that you find lacking in FreeBSD. Mentoring someone is a great idea, but it doesn't end up working too well in a volunteer project. Contribution works best when it's self motivated. If you can't think of anything to do, Andrew's suggestion of looking through the PR database is a good one. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects that need to be done...
On Thu, 6 Jun 2002, Trish Lynch wrote: > what types of things can be done by people who are generally just > learning thier way around some of the code? is there anyone willing to You could go through the PR database and see if there are any problems reported that you could solve. If you can't actually solve it it doesn't matter...you're further analysis may be enough to help someone else fix it...you could post your results to the mailing list...i.e I was looking at PR x and I found this, this and this. I think the problem is line x in x.c but I'm not sure what the correct solution is... Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: projects that need to be done...
Actually don;t worry about this Forget it, really, I was just hoping someone wouldn;t mind someone to "mold" into a generally decent workhorse. -Trish -- Trish Lynch [EMAIL PROTECTED] FreeBSD The Power to Serve Ecartis Core Team [EMAIL PROTECTED] http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
projects that need to be done...
Question: what types of things can be done by people who are generally just learning thier way around some of the code? is there anyone willing to patiently work with a fast learner (yes, honestly my biggest fear is since that I'm entirely self taught is that I have some bad habits, and someone must be willing to LART me at every opportunity on them until I learn) I take intruction well, and I am willing at admit I know NOTHING and am willing to learn. Someone need help on anything they see that I can help out with in my unemployed spare time? I'd even be willing to jump into the deep end if there's someone williong to teach me how to tread water. -Trish -- Trish Lynch [EMAIL PROTECTED] FreeBSD The Power to Serve Ecartis Core Team [EMAIL PROTECTED] http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
On Fri, Jul 27, 2001 at 10:58:55AM -0400, Louis A. Mamakos wrote: > > Matthew Emmerton([EMAIL PROTECTED])@2001.07.26 16:50:52 +: > > > On Thu, 26 Jul 2001, Matthew Jacob wrote: > > > > > > > It'd be nice if one could pass a time specification to at in the form of "next > > > > reboot". > > > > > > > > -matt > > > > > > > > > > Why not just write a script for the command and stick it in > > > /usr/local/etc/rc.d? > > > > because a uid != 0 won't write a startup file there, won't he? ;-) > > Of course, he could use the crontab(1) command, and install an > entry with a time of '@reboot'. > > RTFM: man 1 crontab > man 5 crontab > > Sure, this starts something on *every* reboot, but that's the same > as if you installed someting in /usr/local/etc/rc.d [CC list trimmed viciously] So cron allows a @reboot specification, but at(1) (which is invoked by cron, btw - but that's an implementation detail) does not? This seems like lack of parallelism.. IMHO, there's nothing wrong in adding that functionality to at(1). If people don't like it, they won't use it :) G'luck, Peter -- This sentence was in the past tense. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
In my opinion- this looks pretty good! I'll give it a try later today! Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
> Matthew Emmerton([EMAIL PROTECTED])@2001.07.26 16:50:52 +: > > On Thu, 26 Jul 2001, Matthew Jacob wrote: > > > > > It'd be nice if one could pass a time specification to at in the form of "next > > > reboot". > > > > > > -matt > > > > > > > Why not just write a script for the command and stick it in > > /usr/local/etc/rc.d? > > because a uid != 0 won't write a startup file there, won't he? ;-) Of course, he could use the crontab(1) command, and install an entry with a time of '@reboot'. RTFM: man 1 crontab man 5 crontab Sure, this starts something on *every* reboot, but that's the same as if you installed someting in /usr/local/etc/rc.d louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
Matthew Emmerton([EMAIL PROTECTED])@2001.07.26 16:50:52 +: > On Thu, 26 Jul 2001, Matthew Jacob wrote: > > > It'd be nice if one could pass a time specification to at in the form of "next > > reboot". > > > > -matt > > > > Why not just write a script for the command and stick it in > /usr/local/etc/rc.d? because a uid != 0 won't write a startup file there, won't he? ;-) /k > > -- > Matt Emmerton > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- > A Puritan is someone who is deathly afraid that someone, somewhere, is > having fun. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x PGP signature
Re[8]: perhaps one of phk's "intern" projects?
> Well, thank you for your contributions. Go off and play with RSTS or something > equally suitable. :) thank you man... I wasn't intended to make you feel somewhat unpleasant, so I'm really going off this topic, wishing you good luck. -- Igor > On Fri, 27 Jul 2001, Igor Podlesny wrote: >> >> > You're being somewhat obtuse. >> >> Really? it's probably because I don't multiply apple * milk wishing to >> receive gasoline in answer. >> >> > Complicated times such as 'teatime' and 'reboot' are explicitly allowed. >> >> It isn't a fact, what a pity... >> >> As I said before teatime is strictly defined in the manual... If you >> permanently reboots your system at "teatime" give us a call (911) >> >> > On Fri, 27 Jul 2001, Igor Podlesny wrote: >> >> >> >> >> >> >> >> >> > Hmm. >> >> >> >> > 'at teatime' >> >> >> >> > seems the same as >> >> >> >> > 'at reboot' >> >> >> >> excerpt from man 1 at which can be seen at >> >> >> >> >http://www.freebsd.org/cgi/man.cgi?query=at&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html >> >> >> >> "...You may also specify midnight, noon, or teatime (4pm) and you can >> >> have..." >> >> >> >> So you mean you always reboot your system at 4pm? ;) >> >> >> >> >> >> > On Fri, 27 Jul 2001, Igor Podlesny wrote: >> >> >> >> >> >> >> >> > On Thu, 26 Jul 2001, Matthew Jacob wrote: >> >> >> >> It'd be nice if one could pass a time specification to at in the form >> >> >> >> of "next reboot". >> >> >> >> >> >> look... there is a big difference between time specification in >> >> >> at-program and suggested reboot keyword... I'd say it is like >> >> >> incompatible types... messing up time values and conditions like reboot >> >> >> which are certainly kept within time but AREN'T time values by itself. >> >> >> >> >> >> from man: >> >> >> "... >> >> >> At allows some moderately complex time specifications. >> >> >> ..." >> >> >> >> >> >> but it's always foreseen when precisely the action will have it place >> >> >> if the power is on and everything in system works ok. >> >> >> In case of reboot, this statement fails. >> >> >> >> >> >> So, I deem, it's not worth implementation within 'at' syntax. If >> >> >> somebody want such thing as 'do something on the next reboot', let's >> >> >> write another program (call it onreboot for e.g.) and try to use it. >> >> >> Although I bet, it isn't so necessary as it could seemed at first >> >> >> glance. >> >> >> >> >> >> >> >> >> >> >> >> >> >> -matt >> >> >> >> >> >> > On Thu, 26 Jul 2001, Matthew Emmerton replied: >> >> >> >> Why not just write a script for the command and stick it in >> >> >> >> /usr/local/etc/rc.d? >> >> >> >> >> >> >> >> -- Matt Emmerton >> >> >> >> >> >> > On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied: >> >> >> >> Because I thought this might be of general utility. >> >> >> >> >> >> >> >> >> > Okay, try the attached patch. If this is really something that might be >> >> >> > generally usefully I can submit the patch as a PR. >> >> >> >> >> >> > It allows "at reboot" and "at reboot + 1 hour", etc. >> >> >> >> >> >> > It does it by sticking the job in the queue with the filename prefixed >> >> >> > with "_" (yeah, a bit ugly, it was the first thing that came to me) and >> >> >> > with the runtime based on the epoch instead of the current time. >> >> >> >> >> >> > Adding: >> >> >> > @reboot root /usr/libexec/atrun -b >> >> >> > to /etc/crontab causes atrun(8) to rename all of these jobs adding the >> >> >> > current time to the jobs runtime. >> >> >> >> >> >> >> >> >> > % echo "echo test" | at reboot >> >> >> > Job 19 will be executed using /bin/sh >> >> >> >> >> >> > % echo "echo test" | at reboot + 90 minutes >> >> >> > Job 20 will be executed using /bin/sh >> >> >> >> >> >> > % atq >> >> >> > DateOwner Queue Job# >> >> >> > REBOOT dchapes c 19 >> >> >> > REBOOT+01:30:00 dchapes c 20 >> >> >> >> >> >> what if a user rebooted the box, before this REBOOT+1:30:00 has been >> >> >> occured? will it be discarded or what? >> >> >> >> >> >> > $ date; /usr/libexec/atrun -b >> >> >> >> >> >> > % atq -v >> >> >> > DateOwner Queue Job# >> >> >> > 22:34:00 07/26/01 dchapes c 20 >> >> >> > 21:04:00 07/26/01 dchapes c(done) 19 >> >> >> >> >> >> -- >> >> >> Igormailto:[EMAIL PROTECTED] >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > To Unsubscribe: send mail to [EMAIL PROTECTED] >> >> > with "unsubscribe freebsd-hackers" in the body of the message >> >> >> >> >> >> >> >> -- >> >> Igormailto:[EMAIL PROTECTED] >> >> >> >> >> >> >> >> >> >> -- >> Igormailto:[EMAIL PROTECTED] >> >> >> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re[6]: perhaps one of phk's "intern" projects?
Well, thank you for your contributions. Go off and play with RSTS or something equally suitable. On Fri, 27 Jul 2001, Igor Podlesny wrote: > > > You're being somewhat obtuse. > > Really? it's probably because I don't multiply apple * milk wishing to > receive gasoline in answer. > > > Complicated times such as 'teatime' and 'reboot' are explicitly allowed. > > It isn't a fact, what a pity... > > As I said before teatime is strictly defined in the manual... If you > permanently reboots your system at "teatime" give us a call (911) > > > On Fri, 27 Jul 2001, Igor Podlesny wrote: > > >> > >> > >> > >> > Hmm. > >> > >> > 'at teatime' > >> > >> > seems the same as > >> > >> > 'at reboot' > >> > >> excerpt from man 1 at which can be seen at > >> > >> >http://www.freebsd.org/cgi/man.cgi?query=at&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html > >> > >> "...You may also specify midnight, noon, or teatime (4pm) and you can > >> have..." > >> > >> So you mean you always reboot your system at 4pm? ;) > >> > >> > >> > On Fri, 27 Jul 2001, Igor Podlesny wrote: > >> > >> >> > >> >> > On Thu, 26 Jul 2001, Matthew Jacob wrote: > >> >> >> It'd be nice if one could pass a time specification to at in the form > >> >> >> of "next reboot". > >> >> > >> >> look... there is a big difference between time specification in > >> >> at-program and suggested reboot keyword... I'd say it is like > >> >> incompatible types... messing up time values and conditions like reboot > >> >> which are certainly kept within time but AREN'T time values by itself. > >> >> > >> >> from man: > >> >> "... > >> >> At allows some moderately complex time specifications. > >> >> ..." > >> >> > >> >> but it's always foreseen when precisely the action will have it place > >> >> if the power is on and everything in system works ok. > >> >> In case of reboot, this statement fails. > >> >> > >> >> So, I deem, it's not worth implementation within 'at' syntax. If > >> >> somebody want such thing as 'do something on the next reboot', let's > >> >> write another program (call it onreboot for e.g.) and try to use it. > >> >> Although I bet, it isn't so necessary as it could seemed at first > >> >> glance. > >> >> > >> >> > >> >> >> > >> >> >> -matt > >> >> > >> >> > On Thu, 26 Jul 2001, Matthew Emmerton replied: > >> >> >> Why not just write a script for the command and stick it in > >> >> >> /usr/local/etc/rc.d? > >> >> >> > >> >> >> -- Matt Emmerton > >> >> > >> >> > On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied: > >> >> >> Because I thought this might be of general utility. > >> >> > >> >> > >> >> > Okay, try the attached patch. If this is really something that might be > >> >> > generally usefully I can submit the patch as a PR. > >> >> > >> >> > It allows "at reboot" and "at reboot + 1 hour", etc. > >> >> > >> >> > It does it by sticking the job in the queue with the filename prefixed > >> >> > with "_" (yeah, a bit ugly, it was the first thing that came to me) and > >> >> > with the runtime based on the epoch instead of the current time. > >> >> > >> >> > Adding: > >> >> > @reboot root /usr/libexec/atrun -b > >> >> > to /etc/crontab causes atrun(8) to rename all of these jobs adding the > >> >> > current time to the jobs runtime. > >> >> > >> >> > >> >> > % echo "echo test" | at reboot > >> >> > Job 19 will be executed using /bin/sh > >> >> > >> >> > % echo "echo test" | at reboot + 90 minutes > >> >> > Job 20 will be executed using /bin/sh > >> >> > >> >> > % atq > >> >> > DateOwner Queue Job# > >> >> > REBOOT dchapes c 19 > >> >> > REBOOT+01:30:00 dchapes c 20 > >> >> > >> >> what if a user rebooted the box, before this REBOOT+1:30:00 has been > >> >> occured? will it be discarded or what? > >> >> > >> >> > $ date; /usr/libexec/atrun -b > >> >> > >> >> > % atq -v > >> >> > DateOwner Queue Job# > >> >> > 22:34:00 07/26/01 dchapes c 20 > >> >> > 21:04:00 07/26/01 dchapes c(done) 19 > >> >> > >> >> -- > >> >> Igormailto:[EMAIL PROTECTED] > >> >> > >> >> > >> >> > >> > >> > >> > To Unsubscribe: send mail to [EMAIL PROTECTED] > >> > with "unsubscribe freebsd-hackers" in the body of the message > >> > >> > >> > >> -- > >> Igormailto:[EMAIL PROTECTED] > >> > >> > >> > > > > -- > Igormailto:[EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[6]: perhaps one of phk's "intern" projects?
> You're being somewhat obtuse. Really? it's probably because I don't multiply apple * milk wishing to receive gasoline in answer. > Complicated times such as 'teatime' and 'reboot' are explicitly allowed. It isn't a fact, what a pity... As I said before teatime is strictly defined in the manual... If you permanently reboots your system at "teatime" give us a call (911) > On Fri, 27 Jul 2001, Igor Podlesny wrote: >> >> >> >> > Hmm. >> >> > 'at teatime' >> >> > seems the same as >> >> > 'at reboot' >> >> excerpt from man 1 at which can be seen at >> >> >http://www.freebsd.org/cgi/man.cgi?query=at&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html >> >> "...You may also specify midnight, noon, or teatime (4pm) and you can >> have..." >> >> So you mean you always reboot your system at 4pm? ;) >> >> >> > On Fri, 27 Jul 2001, Igor Podlesny wrote: >> >> >> >> >> > On Thu, 26 Jul 2001, Matthew Jacob wrote: >> >> >> It'd be nice if one could pass a time specification to at in the form >> >> >> of "next reboot". >> >> >> >> look... there is a big difference between time specification in >> >> at-program and suggested reboot keyword... I'd say it is like >> >> incompatible types... messing up time values and conditions like reboot >> >> which are certainly kept within time but AREN'T time values by itself. >> >> >> >> from man: >> >> "... >> >> At allows some moderately complex time specifications. >> >> ..." >> >> >> >> but it's always foreseen when precisely the action will have it place >> >> if the power is on and everything in system works ok. >> >> In case of reboot, this statement fails. >> >> >> >> So, I deem, it's not worth implementation within 'at' syntax. If >> >> somebody want such thing as 'do something on the next reboot', let's >> >> write another program (call it onreboot for e.g.) and try to use it. >> >> Although I bet, it isn't so necessary as it could seemed at first >> >> glance. >> >> >> >> >> >> >> >> >> >> -matt >> >> >> >> > On Thu, 26 Jul 2001, Matthew Emmerton replied: >> >> >> Why not just write a script for the command and stick it in >> >> >> /usr/local/etc/rc.d? >> >> >> >> >> >> -- Matt Emmerton >> >> >> >> > On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied: >> >> >> Because I thought this might be of general utility. >> >> >> >> >> >> > Okay, try the attached patch. If this is really something that might be >> >> > generally usefully I can submit the patch as a PR. >> >> >> >> > It allows "at reboot" and "at reboot + 1 hour", etc. >> >> >> >> > It does it by sticking the job in the queue with the filename prefixed >> >> > with "_" (yeah, a bit ugly, it was the first thing that came to me) and >> >> > with the runtime based on the epoch instead of the current time. >> >> >> >> > Adding: >> >> > @reboot root /usr/libexec/atrun -b >> >> > to /etc/crontab causes atrun(8) to rename all of these jobs adding the >> >> > current time to the jobs runtime. >> >> >> >> >> >> > % echo "echo test" | at reboot >> >> > Job 19 will be executed using /bin/sh >> >> >> >> > % echo "echo test" | at reboot + 90 minutes >> >> > Job 20 will be executed using /bin/sh >> >> >> >> > % atq >> >> > DateOwner Queue Job# >> >> > REBOOT dchapes c 19 >> >> > REBOOT+01:30:00 dchapes c 20 >> >> >> >> what if a user rebooted the box, before this REBOOT+1:30:00 has been >> >> occured? will it be discarded or what? >> >> >> >> > $ date; /usr/libexec/atrun -b >> >> >> >> > % atq -v >> >> > DateOwner Queue Job# >> >> > 22:34:00 07/26/01 dchapes c 20 >> >> > 21:04:00 07/26/01 dchapes c(done) 19 >> >> >> >> -- >> >> Igormailto:[EMAIL PROTECTED] >> >> >> >> >> >> >> >> >> > To Unsubscribe: send mail to [EMAIL PROTECTED] >> > with "unsubscribe freebsd-hackers" in the body of the message >> >> >> >> -- >> Igormailto:[EMAIL PROTECTED] >> >> >> -- Igormailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re[4]: perhaps one of phk's "intern" projects?
You're being somewhat obtuse. Complicated times such as 'teatime' and 'reboot' are explicitly allowed. On Fri, 27 Jul 2001, Igor Podlesny wrote: > > > > > Hmm. > > > 'at teatime' > > > seems the same as > > > 'at reboot' > > excerpt from man 1 at which can be seen at > > >http://www.freebsd.org/cgi/man.cgi?query=at&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html > > "...You may also specify midnight, noon, or teatime (4pm) and you can > have..." > > So you mean you always reboot your system at 4pm? ;) > > > > On Fri, 27 Jul 2001, Igor Podlesny wrote: > > >> > >> > On Thu, 26 Jul 2001, Matthew Jacob wrote: > >> >> It'd be nice if one could pass a time specification to at in the form > >> >> of "next reboot". > >> > >> look... there is a big difference between time specification in > >> at-program and suggested reboot keyword... I'd say it is like > >> incompatible types... messing up time values and conditions like reboot > >> which are certainly kept within time but AREN'T time values by itself. > >> > >> from man: > >> "... > >> At allows some moderately complex time specifications. > >> ..." > >> > >> but it's always foreseen when precisely the action will have it place > >> if the power is on and everything in system works ok. > >> In case of reboot, this statement fails. > >> > >> So, I deem, it's not worth implementation within 'at' syntax. If > >> somebody want such thing as 'do something on the next reboot', let's > >> write another program (call it onreboot for e.g.) and try to use it. > >> Although I bet, it isn't so necessary as it could seemed at first > >> glance. > >> > >> > >> >> > >> >> -matt > >> > >> > On Thu, 26 Jul 2001, Matthew Emmerton replied: > >> >> Why not just write a script for the command and stick it in > >> >> /usr/local/etc/rc.d? > >> >> > >> >> -- Matt Emmerton > >> > >> > On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied: > >> >> Because I thought this might be of general utility. > >> > >> > >> > Okay, try the attached patch. If this is really something that might be > >> > generally usefully I can submit the patch as a PR. > >> > >> > It allows "at reboot" and "at reboot + 1 hour", etc. > >> > >> > It does it by sticking the job in the queue with the filename prefixed > >> > with "_" (yeah, a bit ugly, it was the first thing that came to me) and > >> > with the runtime based on the epoch instead of the current time. > >> > >> > Adding: > >> > @reboot root /usr/libexec/atrun -b > >> > to /etc/crontab causes atrun(8) to rename all of these jobs adding the > >> > current time to the jobs runtime. > >> > >> > >> > % echo "echo test" | at reboot > >> > Job 19 will be executed using /bin/sh > >> > >> > % echo "echo test" | at reboot + 90 minutes > >> > Job 20 will be executed using /bin/sh > >> > >> > % atq > >> > DateOwner Queue Job# > >> > REBOOT dchapes c 19 > >> > REBOOT+01:30:00 dchapes c 20 > >> > >> what if a user rebooted the box, before this REBOOT+1:30:00 has been > >> occured? will it be discarded or what? > >> > >> > $ date; /usr/libexec/atrun -b > >> > >> > % atq -v > >> > DateOwner Queue Job# > >> > 22:34:00 07/26/01 dchapes c 20 > >> > 21:04:00 07/26/01 dchapes c(done) 19 > >> > >> -- > >> Igormailto:[EMAIL PROTECTED] > >> > >> > >> > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > > > -- > Igormailto:[EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[4]: perhaps one of phk's "intern" projects?
> Hmm. > 'at teatime' > seems the same as > 'at reboot' excerpt from man 1 at which can be seen at http://www.freebsd.org/cgi/man.cgi?query=at&apropos=0&sektion=0&manpath=FreeBSD+4.3-RELEASE&format=html "...You may also specify midnight, noon, or teatime (4pm) and you can have..." So you mean you always reboot your system at 4pm? ;) > On Fri, 27 Jul 2001, Igor Podlesny wrote: >> >> > On Thu, 26 Jul 2001, Matthew Jacob wrote: >> >> It'd be nice if one could pass a time specification to at in the form >> >> of "next reboot". >> >> look... there is a big difference between time specification in >> at-program and suggested reboot keyword... I'd say it is like >> incompatible types... messing up time values and conditions like reboot >> which are certainly kept within time but AREN'T time values by itself. >> >> from man: >> "... >> At allows some moderately complex time specifications. >> ..." >> >> but it's always foreseen when precisely the action will have it place >> if the power is on and everything in system works ok. >> In case of reboot, this statement fails. >> >> So, I deem, it's not worth implementation within 'at' syntax. If >> somebody want such thing as 'do something on the next reboot', let's >> write another program (call it onreboot for e.g.) and try to use it. >> Although I bet, it isn't so necessary as it could seemed at first >> glance. >> >> >> >> >> >> -matt >> >> > On Thu, 26 Jul 2001, Matthew Emmerton replied: >> >> Why not just write a script for the command and stick it in >> >> /usr/local/etc/rc.d? >> >> >> >> -- Matt Emmerton >> >> > On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied: >> >> Because I thought this might be of general utility. >> >> >> > Okay, try the attached patch. If this is really something that might be >> > generally usefully I can submit the patch as a PR. >> >> > It allows "at reboot" and "at reboot + 1 hour", etc. >> >> > It does it by sticking the job in the queue with the filename prefixed >> > with "_" (yeah, a bit ugly, it was the first thing that came to me) and >> > with the runtime based on the epoch instead of the current time. >> >> > Adding: >> > @reboot root /usr/libexec/atrun -b >> > to /etc/crontab causes atrun(8) to rename all of these jobs adding the >> > current time to the jobs runtime. >> >> >> > % echo "echo test" | at reboot >> > Job 19 will be executed using /bin/sh >> >> > % echo "echo test" | at reboot + 90 minutes >> > Job 20 will be executed using /bin/sh >> >> > % atq >> > DateOwner Queue Job# >> > REBOOT dchapes c 19 >> > REBOOT+01:30:00 dchapes c 20 >> >> what if a user rebooted the box, before this REBOOT+1:30:00 has been >> occured? will it be discarded or what? >> >> > $ date; /usr/libexec/atrun -b >> >> > % atq -v >> > DateOwner Queue Job# >> > 22:34:00 07/26/01 dchapes c 20 >> > 21:04:00 07/26/01 dchapes c(done) 19 >> >> -- >> Igormailto:[EMAIL PROTECTED] >> >> >> > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Igormailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re[2]: perhaps one of phk's "intern" projects?
Hmm. 'at teatime' seems the same as 'at reboot' On Fri, 27 Jul 2001, Igor Podlesny wrote: > > > On Thu, 26 Jul 2001, Matthew Jacob wrote: > >> It'd be nice if one could pass a time specification to at in the form > >> of "next reboot". > > look... there is a big difference between time specification in > at-program and suggested reboot keyword... I'd say it is like > incompatible types... messing up time values and conditions like reboot > which are certainly kept within time but AREN'T time values by itself. > > from man: > "... > At allows some moderately complex time specifications. > ..." > > but it's always foreseen when precisely the action will have it place > if the power is on and everything in system works ok. > In case of reboot, this statement fails. > > So, I deem, it's not worth implementation within 'at' syntax. If > somebody want such thing as 'do something on the next reboot', let's > write another program (call it onreboot for e.g.) and try to use it. > Although I bet, it isn't so necessary as it could seemed at first > glance. > > > >> > >> -matt > > > On Thu, 26 Jul 2001, Matthew Emmerton replied: > >> Why not just write a script for the command and stick it in > >> /usr/local/etc/rc.d? > >> > >> -- Matt Emmerton > > > On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied: > >> Because I thought this might be of general utility. > > > > Okay, try the attached patch. If this is really something that might be > > generally usefully I can submit the patch as a PR. > > > It allows "at reboot" and "at reboot + 1 hour", etc. > > > It does it by sticking the job in the queue with the filename prefixed > > with "_" (yeah, a bit ugly, it was the first thing that came to me) and > > with the runtime based on the epoch instead of the current time. > > > Adding: > > @reboot root /usr/libexec/atrun -b > > to /etc/crontab causes atrun(8) to rename all of these jobs adding the > > current time to the jobs runtime. > > > > % echo "echo test" | at reboot > > Job 19 will be executed using /bin/sh > > > % echo "echo test" | at reboot + 90 minutes > > Job 20 will be executed using /bin/sh > > > % atq > > DateOwner Queue Job# > > REBOOT dchapes c 19 > > REBOOT+01:30:00 dchapes c 20 > > what if a user rebooted the box, before this REBOOT+1:30:00 has been > occured? will it be discarded or what? > > > $ date; /usr/libexec/atrun -b > > > % atq -v > > DateOwner Queue Job# > > 22:34:00 07/26/01 dchapes c 20 > > 21:04:00 07/26/01 dchapes c(done) 19 > > -- > Igormailto:[EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[2]: perhaps one of phk's "intern" projects?
> On Thu, 26 Jul 2001, Matthew Jacob wrote: >> It'd be nice if one could pass a time specification to at in the form >> of "next reboot". look... there is a big difference between time specification in at-program and suggested reboot keyword... I'd say it is like incompatible types... messing up time values and conditions like reboot which are certainly kept within time but AREN'T time values by itself. from man: "... At allows some moderately complex time specifications. ..." but it's always foreseen when precisely the action will have it place if the power is on and everything in system works ok. In case of reboot, this statement fails. So, I deem, it's not worth implementation within 'at' syntax. If somebody want such thing as 'do something on the next reboot', let's write another program (call it onreboot for e.g.) and try to use it. Although I bet, it isn't so necessary as it could seemed at first glance. >> >> -matt > On Thu, 26 Jul 2001, Matthew Emmerton replied: >> Why not just write a script for the command and stick it in >> /usr/local/etc/rc.d? >> >> -- Matt Emmerton > On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied: >> Because I thought this might be of general utility. > Okay, try the attached patch. If this is really something that might be > generally usefully I can submit the patch as a PR. > It allows "at reboot" and "at reboot + 1 hour", etc. > It does it by sticking the job in the queue with the filename prefixed > with "_" (yeah, a bit ugly, it was the first thing that came to me) and > with the runtime based on the epoch instead of the current time. > Adding: > @reboot root /usr/libexec/atrun -b > to /etc/crontab causes atrun(8) to rename all of these jobs adding the > current time to the jobs runtime. > % echo "echo test" | at reboot > Job 19 will be executed using /bin/sh > % echo "echo test" | at reboot + 90 minutes > Job 20 will be executed using /bin/sh > % atq > DateOwner Queue Job# > REBOOT dchapes c 19 > REBOOT+01:30:00 dchapes c 20 what if a user rebooted the box, before this REBOOT+1:30:00 has been occured? will it be discarded or what? > $ date; /usr/libexec/atrun -b > % atq -v > DateOwner Queue Job# > 22:34:00 07/26/01 dchapes c 20 > 21:04:00 07/26/01 dchapes c(done) 19 -- Igormailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
Matthew Jacob wrote: > > On Thu, 26 Jul 2001, Matthew Emmerton wrote: > > > On Thu, 26 Jul 2001, Matthew Jacob wrote: > > > > > It'd be nice if one could pass a time specification to at in the form of "next > > > reboot". > > > > > > -matt > > > > > > > Why not just write a script for the command and stick it in > > /usr/local/etc/rc.d? > > Because I thought this might be of general utility. 'at next reboot' would only be run once, on the NEXT reboot, right? rc.d is for things you want run on EVERY reboot. This does almost smack of Microsoft, though. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
On Thu, 26 Jul 2001, Matthew Jacob wrote:
> It'd be nice if one could pass a time specification to at in the form
> of "next reboot".
>
> -matt
On Thu, 26 Jul 2001, Matthew Emmerton replied:
> Why not just write a script for the command and stick it in
> /usr/local/etc/rc.d?
>
> -- Matt Emmerton
On Thu, Jul 26, 2001 at 03:45:58PM -0700, Matthew Jacob replied:
> Because I thought this might be of general utility.
Okay, try the attached patch. If this is really something that might be
generally usefully I can submit the patch as a PR.
It allows "at reboot" and "at reboot + 1 hour", etc.
It does it by sticking the job in the queue with the filename prefixed
with "_" (yeah, a bit ugly, it was the first thing that came to me) and
with the runtime based on the epoch instead of the current time.
Adding:
@reboot root /usr/libexec/atrun -b
to /etc/crontab causes atrun(8) to rename all of these jobs adding the
current time to the jobs runtime.
% echo "echo test" | at reboot
Job 19 will be executed using /bin/sh
% echo "echo test" | at reboot + 90 minutes
Job 20 will be executed using /bin/sh
% atq
DateOwner Queue Job#
REBOOT dchapes c 19
REBOOT+01:30:00 dchapes c 20
$ date; /usr/libexec/atrun -b
% atq -v
DateOwner Queue Job#
22:34:00 07/26/01 dchapes c 20
21:04:00 07/26/01 dchapes c(done) 19
--
Dave Chapeskie <[EMAIL PROTECTED]>
OpenPGP Key KeyId: 3D2B6B34
Index: usr.bin/at/at.h
===
RCS file: /cvs/FreeBSD/src/usr.bin/at/at.h,v
retrieving revision 1.5
diff -u -r1.5 at.h
--- usr.bin/at/at.h 2001/07/24 14:15:51 1.5
+++ usr.bin/at/at.h 2001/07/26 22:38:53
@@ -29,3 +29,4 @@
extern char *namep;
extern char atfile[];
extern char atverify;
+extern int reboot_time;
Index: usr.bin/at/parsetime.c
===
RCS file: /cvs/FreeBSD/src/usr.bin/at/parsetime.c,v
retrieving revision 1.21
diff -u -r1.21 parsetime.c
--- usr.bin/at/parsetime.c 2001/07/24 14:15:51 1.21
+++ usr.bin/at/parsetime.c 2001/07/26 23:28:28
@@ -25,7 +25,7 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
- * at [NOW] PLUS NUMBER MINUTES|HOURS|DAYS|WEEKS
+ * at [NOW|REBOOT] PLUS NUMBER MINUTES|HOURS|DAYS|WEEKS
* /NUMBER [DOT NUMBER] [AM|PM]\ /[MONTH NUMBER [NUMBER]] \
* |NOON | |[TOMORROW] |
* |MIDNIGHT | |[DAY OF WEEK] |
@@ -63,7 +63,7 @@
enum { /* symbols */
MIDNIGHT, NOON, TEATIME,
-PM, AM, TOMORROW, TODAY, NOW,
+PM, AM, TOMORROW, TODAY, NOW, REBOOT,
MINUTES, HOURS, DAYS, WEEKS, MONTHS, YEARS,
NUMBER, PLUS, DOT, SLASH, ID, JUNK,
JAN, FEB, MAR, APR, MAY, JUN,
@@ -86,6 +86,7 @@
{ "tomorrow", TOMORROW,0 },/* execute 24 hours from time */
{ "today", TODAY, 0 }, /* execute today - don't advance time */
{ "now", NOW,0 }, /* opt prefix for PLUS */
+{ "reboot", REBOOT, 0 }, /* execute on next reboot */
{ "minute", MINUTES,0 }, /* minutes multiplier */
{ "minutes", MINUTES,1 }, /* (pluralized) */
@@ -280,7 +281,7 @@
/*
* plus() parses a now + time
*
- * at [NOW] PLUS NUMBER [MINUTES|HOURS|DAYS|WEEKS|MONTHS|YEARS]
+ * at [NOW|REBOOT] PLUS NUMBER [MINUTES|HOURS|DAYS|WEEKS|MONTHS|YEARS]
*
*/
@@ -563,6 +564,7 @@
*/
time_t nowtimer, runtimer;
struct tm nowtime, runtime;
+int t;
int hr = 0;
/* this MUST be initialized to zero for midnight/noon/teatime */
@@ -579,6 +581,22 @@
init_scanner(argc-optind, argv+optind);
switch (token()) {
+case REBOOT:
+ reboot_time = 1;
+ /* Reset "now" to be the epoch */
+ nowtimer = 0;
+ nowtime = *localtime(&nowtimer);
+ runtime = nowtime;
+ runtime.tm_sec = 0;
+ runtime.tm_isdst = 0;
+
+ t = token();
+ if (t == PLUS)
+ plus(&runtime);
+ else if (t != EOF)
+ plonk(sc_tokid);
+ break;
+
case NOW: /* now is optional prefix for PLUS tree */
expect(PLUS);
case PLUS:
Index: usr.bin/at/at.c
===
RCS file: /cvs/FreeBSD/src/usr.bin/at/at.c,v
retrieving revision 1.19
diff -u -r1.19 at.c
--- usr.bin/at/at.c 2001/07/24 14:15:51 1.19
+++ usr.bin/at/at.c 2001/07/26 23:53:47
@@ -108,7 +108,8 @@
extern char **environ;
int fcreated;
-char atfile[] = ATJOB_DIR "12345678901234";
+char atfile[] = ATJOB_DIR "_Q1234512345678";
+int reboot_time = 0; /* if 'reboot' was specified */
char *atinput = (char*)0; /* where to get input from */
char atqueue = 0;
Re: perhaps one of phk's "intern" projects?
Because I thought this might be of general utility. On Thu, 26 Jul 2001, Matthew Emmerton wrote: > On Thu, 26 Jul 2001, Matthew Jacob wrote: > > > It'd be nice if one could pass a time specification to at in the form of "next > > reboot". > > > > -matt > > > > Why not just write a script for the command and stick it in > /usr/local/etc/rc.d? > > -- > Matt Emmerton > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
On Thu, 26 Jul 2001, Matthew Jacob wrote: > It'd be nice if one could pass a time specification to at in the form of "next > reboot". > > -matt > Why not just write a script for the command and stick it in /usr/local/etc/rc.d? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
at already understands the concept of "tomorrow" in it's parsing of time. It also understands special terms like "teatime". If we simplify this to at reboot then all you'd have to do would be to either squirrel these jobs in another directory and have part of rc check for these or just have a special name so that at's reading of the spool dir won't get upset if they're ther. On Thu, 26 Jul 2001, Peter Pentchev wrote: > On Thu, Jul 26, 2001 at 10:20:51AM -0700, Matthew Jacob wrote: > > > > It'd be nice if one could pass a time specification to at in the form of "next > > reboot". > > This could be implemented as a startup script, no? > On second thoughts, not quite trivial. > > It wouldn't be hard to write a separate utility to schedule jobs to be > serviced at the next reboot; integrating this functionality into at(1) > would be nice, too, though maybe just a little bit harder - it would > require the time to parse the at(1) sources ;) Then it would be > as simple as making the command-line scheduling utility write the job > into the at-next-boot utility spool dir instead of the regular at(1) > spool dir; or maybe the at-next-boot utility could just look through > the regular at(1) spool dir for some specially-marked files that at(1) > would ignore.. > > I would be willing to do this, if no one else volunteers. > > G'luck, > Peter > > -- > This would easier understand fewer had omitted. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
On Thu, Jul 26, 2001 at 10:20:51AM -0700, Matthew Jacob wrote: > > It'd be nice if one could pass a time specification to at in the form of "next > reboot". This could be implemented as a startup script, no? On second thoughts, not quite trivial. It wouldn't be hard to write a separate utility to schedule jobs to be serviced at the next reboot; integrating this functionality into at(1) would be nice, too, though maybe just a little bit harder - it would require the time to parse the at(1) sources ;) Then it would be as simple as making the command-line scheduling utility write the job into the at-next-boot utility spool dir instead of the regular at(1) spool dir; or maybe the at-next-boot utility could just look through the regular at(1) spool dir for some specially-marked files that at(1) would ignore.. I would be willing to do this, if no one else volunteers. G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
perhaps one of phk's "intern" projects?
It'd be nice if one could pass a time specification to at in the form of "next reboot". -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Call for projects
Since no-one except Poul-Henning gave a start with this I thought I might try my hand at this. Given FreeBSD's rapid development over the last year a lot of things around the releases have changed. Nik Clayton and his team are doing a terrific job to keep up with the documentation. However, what has been lacking, at least in my opinion, is the lack of alerting less advanced, more time-restrained, however you wish to call it, hackers of tasks which need to be fixed in FreeBSD. The PR system is nice and works pretty well [thanks to a lot of people] but it is not what I meant with my above words. What I did mean though, is that when someone messes with source code at large in FreeBSD to let the hacker/developer-community know of these changes plus point out some areas which need to be fixed/looked-out with these patches in place. Small-term projects. Also, put out more patches on either -hackers or -current [depending on what platform the patches aim at] and call for more test reviews to eliminate more and more initial bugs upon introducing. Plus, let the doc guys know what changes have been made and in which places the docs should be altered. Doesn't take much, but remember that not every docperson is a kernel hacker and vice versa, so UTSL, how well intended doesn't always help in these cases. All of this is merely a call for clearer communication between the diverse efforts within the project as a whole and external hackers with no access to the repository but who wish to send-pr diffs/patches to fix up forgotten/neglected/overseen areas in the code. Thanking you all in advance for helping on this. It's together we make this project work... -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai> Network/Security SpecialistBSD: Technical excellence at its best Any fool can make a rule And every fool will mind it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
