Re: USB stack / configuration 0
On Wednesday 07 January 2004 17:08, Bernd Walter wrote: I don't think it IS a dumb device, there is a USB spec called DFU which covers it and the hosts job is to do the reenumeration. Sparing a transistor to offload the work to the host were its also way more complex to do is dump. If this is part of the Spec, then the spec is dump too. Err yes, this IS USB we're talking about here :) usbd_reset_port should do from the USB point of view, but this doesn't trigger Free BSD to do a reconfiguration of the device, which is required after reset. Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. Except that would remove power to the port I think.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wed, Jan 07, 2004 at 05:34:05PM +1030, Daniel O'Connor wrote: On Wednesday 07 January 2004 17:08, Bernd Walter wrote: I don't think it IS a dumb device, there is a USB spec called DFU which covers it and the hosts job is to do the reenumeration. Sparing a transistor to offload the work to the host were its also way more complex to do is dump. If this is part of the Spec, then the spec is dump too. Err yes, this IS USB we're talking about here :) Reead your spec - it's not part of USB itself. umass, ulpt, etc are extensions. It is even that a mass storage device doesn't have to honour umass specification to get the USB compliance logo :( usbd_reset_port should do from the USB point of view, but this doesn't trigger Free BSD to do a reconfiguration of the device, which is required after reset. Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. Except that would remove power to the port I think.. AFAIK power is independend, but I'm not 100% shure. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wednesday 07 January 2004 09:07, Bernd Walter wrote: On Wed, Jan 07, 2004 at 05:34:05PM +1030, Daniel O'Connor wrote: On Wednesday 07 January 2004 17:08, Bernd Walter wrote: I don't think it IS a dumb device, there is a USB spec called DFU which covers it and the hosts job is to do the reenumeration. Sparing a transistor to offload the work to the host were its also way more complex to do is dump. If this is part of the Spec, then the spec is dump too. Err yes, this IS USB we're talking about here :) Reead your spec - it's not part of USB itself. As long as there are a lot of usefull devices that use the DFU spec, to me it seems no more than logicle to implement it in FreeBSD, no matter how dumb the system may sound :) usbd_reset_port should do from the USB point of view, but this doesn't trigger Free BSD to do a reconfiguration of the device, which is required after reset. Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. Except that would remove power to the port I think.. AFAIK power is independend, but I'm not 100% shure. I have written a driver for Atmel USB WLAN adapters for FreeBSD recently (and still am). The device also needs it's firmware to be uploaded via the DFU interface. The first time the device is plugged in, an internal ROM mask is mapped into code-space of the processor which provides it with only a very basic USB stack that can do enumeration and DFU. Via DFU the host uploads the firmware into RAM. At the end of the upload the host asks the device to manifest the firmware. For the device this means having to switch the ROM image with the RAM image which is impossible while running in the specific processor. Thus the processor tells it's core to map RAM into code-space and resets itself. After that the device will apear again with address = 0. The host then needs to set the address, re-read the device descriptor (it has changes, the device now offers endpoints etc), attach a driver. Btw, a reset can be sent down to a usb device from within a driver with this line of code : usb_port_status_t stat; usbd_reset_port(sc-atuwi_udev-myhub, sc-atuwi_udev-powersrc-portno, stat); For my device driver I have made a small change to the USB Stack and I have introduced the return code USB_ATTACH_NEED_RESET for drivers to tell the USB Stack thee device needs to be re-enumerated. The stack then automatically re-assigns the device it's address, and re-probes for drivers. This way even two seperate drivers could be made : one with the firmware and one with the real driver. Is anyone interrested in a patch maybe? btw2: I have submitted a couple of patches in 2003 (one of witch is almost a year old at this moment), but none of the got comments / commited. Is anyone really working on USB code development / debugging lately? I want to see ALL USB devices working with FreeBSD and am willing to devote my spare-time to achieving this. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcng guru needed
after all my confusions, my problem was solved once netif was made executable. danny while hunting down the problem that my diskless configuration is not starting the loopback interface i came about the following: rcorder does not list network, but it does network_ipv6 further checking reveals: in /etc/rc.d/dhclient: # PROVIDE: dhclient # REQUIRE: network netif mountcritlocal # BEFORE: NETWORKING and in /etc/rc.d/NETWORKING: # PROVIDE: NETWORKING NETWORK # REQUIRE: network dhclient altqd netif routing network_ipv6 isdnd ppp-user # REQUIRE: routed mrouted route6d mroute6d no amount of efford has succeeded in getting network on the rcorder list, i.e: in /etc/rc.d/amd # PROVIDE: amd # REQUIRE: network rpcbind mountall nfsclient # BEFORE: DAEMON does not have the requiered effect, so how can i get network to run? (the logic says that it should not requiere network, since nfsclient does). danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcng guru needed
On Wed, Jan 07, 2004 at 01:05:57PM +0200, Danny Braniss wrote: after all my confusions, my problem was solved once netif was made executable. It's always one of those inconspicuous details :) -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Paul Robinson [EMAIL PROTECTED] writes: If 5.3, when it arrives, is genuinely production ready, trust me, the drinks are on me - I will do my absolute best to get to the next BSDcon and get everybody drunk on an expense account. If it isn't, well, I'll just have to whisper I told you so quietly somewhere. I am currently working for an ISP whose infrastructure is based 75% on FreeBSD 5.1. The remaining 25% are a nameserver running 4.7, a mail server and a backup server running 5.2, and a BGP router running a month-old -CURRENT. I am about to start in a new job at a company that builds a high- performance network security appliance based on FreeBSD. The version they travel around with to show off to potential customers runs on -STABLE; the development version runs on -CURRENT. I asked them what it was like to develop on -CURRENT compared to -STABLE. Their answer: a relief. Now tell me again why you think FreeBSD 5 is a disaster, and why you think we're out of touch with our users and admins. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wednesday 07 January 2004 18:37, Bernd Walter wrote: If this is part of the Spec, then the spec is dump too. Err yes, this IS USB we're talking about here :) Reead your spec - it's not part of USB itself. umass, ulpt, etc are extensions. It is even that a mass storage device doesn't have to honour umass specification to get the USB compliance logo :( shrugs I have a sharp axe you can split hairs with if you like. umass/ulpt/dfu/etc are all things that make USB useful, so support is good :) Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. Except that would remove power to the port I think.. AFAIK power is independend, but I'm not 100% shure. I'll see how it goes :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wednesday 07 January 2004 20:34, Daan Vreeken [PA4DAN] wrote: Reead your spec - it's not part of USB itself. As long as there are a lot of usefull devices that use the DFU spec, to me it seems no more than logicle to implement it in FreeBSD, no matter how dumb the system may sound :) Yeah.. well there are plenty of dumb things about USB :) AFAIK power is independend, but I'm not 100% shure. I have written a driver for Atmel USB WLAN adapters for FreeBSD recently (and still am). The device also needs it's firmware to be uploaded via the DFU interface. The first time the device is plugged in, an internal ROM mask is mapped into code-space of the processor which provides it with only a very basic USB stack that can do enumeration and DFU. Via DFU the host uploads the firmware into RAM. At the end of the upload the host asks the device to manifest the firmware. For the device this means having to switch the ROM image with the RAM image which is impossible while running in the specific processor. Thus the processor tells it's core to map RAM into code-space and resets itself. After that the device will apear again with address = 0. The host then needs to set the address, re-read the device descriptor (it has changes, the device now offers endpoints etc), attach a driver. Interesting way of making it :) The device I have uses a Ti chip which has USB primitives and powers up with DFU only support, and then needs a reset to start executing the new code from RAM. Btw, a reset can be sent down to a usb device from within a driver with this line of code : usb_port_status_t stat; usbd_reset_port(sc-atuwi_udev-myhub, sc-atuwi_udev-powersrc-portno, stat); For my device driver I have made a small change to the USB Stack and I have introduced the return code USB_ATTACH_NEED_RESET for drivers to tell the USB Stack thee device needs to be re-enumerated. The stack then automatically re-assigns the device it's address, and re-probes for drivers. This way even two seperate drivers could be made : one with the firmware and one with the real driver. Is anyone interrested in a patch maybe? Ooh yes please :) btw2: I have submitted a couple of patches in 2003 (one of witch is almost a year old at this moment), but none of the got comments / commited. Is anyone really working on USB code development / debugging lately? I want to see ALL USB devices working with FreeBSD and am willing to devote my spare-time to achieving this. I thought Josef Karthauser [EMAIL PROTECTED] was doing some USB work, but I am not certain. I can test some stuff - I have a variety of USB 1 and 2 hardware (USB1 scanner, USB2 card reader, USB1 Pocket PC cradle *hiss* :), mouse, USB2 HD enclosure, USB1 printer and dongle..) I updated by laptop to 5.x recently so that should make this more relevant :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
I wrote: Mark has mailed me off-list. His tone isn't great. I probably deserve the Fuck off. Go away. I'l deal with that seperately. :-) A few things to say about this: 1. I was not quoting Mark verbatim here. He didn't tell me to go away in the same paragraph. :-) 2. It was a private e-mail, and it's tone/content should have stayed as such, and so I was wrong to allow leakage. 3. The specific context of my mail to which he was replying, that caused him to get upset with me was where I stated in public: In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. 4. In private I've already apologised for that particualr comment as I realise now it was very Daily Mail of me to make it (for those of you without access to the Daily Mail, congratualations), and it's only fair as it spilled out onto the public lists, that I apologise here too. Mark also apologised for swearing at me. Oh, and I should also add, in an attempt at public humiliation to make sure I behave better in future that in the e-mail where I replied to Mark privately, I finished with the following: It wasn't meant to be taken as being personally offensive, but I am pissed off that people just said Oh the start of this thread was just a troll, ignore it when there were issues that did need to be raised and aired and discussed that the original post touched on (badly). Now I'm just pissed off that never happened in a constructive manner, and I'm part to blame. I think that is a fair summation, and perhaps a good point to let that particular branch of the thread die. And for those of you who normally shout Submit a patch - well, I'm thinking about it. :-) -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
fwiw, the original mail was mine, written almost a year ago. Date: Tue, 4 Feb 2003 11:15:27 +0100 From: Shaun Jurrens [EMAIL PROTECTED] Subject: dillon@'s commit bit: I object To: [EMAIL PROTECTED] While I still stand by my original thoughts, I didn't reproduce this from any faked e-mail address. This is all in the archives with the ensuing rants. It is a pity that our troll doesn't have any original thoughts of his own... I had to laugh a bit when I saw this... not sure if I'm flattered or insulted. I'd apologize to Maxime, but it wasn't my doing... He's a big boy anyway, and I'm not a troll. -- Yours truly, Shaun D. Jurrens [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
switching between groups
I was just wondering if anyone has any ideas how it's possible for a user that belongs to multiple groups to somehow limit his or her own capabilities by using only one of the n groups that they belong to and be able to switch between these groups? For example, if userA belongs to groupA, groupB and groupC, can userA enter a mode that would force it to only belong to groupA (or groupB, or groupC)? UserA whould be able to switch between these groups and back to normal (ie. belong to all groups). Any help would be appreciated. Adil ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
switching between groups
I was just wondering if anyone has any ideas how it's possible for a user that belongs to multiple groups to somehow limit his or her own capabilities by using only one of the n groups that they belong to and be able to switch between these groups? For example, if userA belongs to groupA, groupB and groupC, can userA enter a mode that would force it to only belong to groupA (or groupB, or groupC)? UserA whould be able to switch between these groups and back to normal (ie. belong to all groups). Any help would be appreciated. Adil ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 5:35 PM + 2004/01/06, Paul Robinson wrote: The cleverness of the troll was: 1. It was written by somebody who at the least had read these lists for at least the last two years Maybe. It would be easy enough to skim the archives. 2. It aired the real frustrations of those of us without commit bits Define us. You sure as hell aren't speaking for me. 3. It was on the whole, apart from the personal attacks, reasonably correct. Evidence, please. And therein lies a problem. The only thing any of the committers cares about is what they think. Got a problem? Submit a patch. Don't like the way things are done? Submit a patch. Don't like how such-and-such a util works? Submit a patch. Not at all true. Mark Murray (among others) has stressed the need for people with different talents to contribute to the project. We need more people who can help us do proper QA. We need more people who can help us write good documentation. We need people who have a lot of skills that are not necessarily related at all to writing code. If you have a set of skills that you think could be useful, please contact Mark or one of the other members of -core to find out how you might be able to contribute to the project. Otherwise, if you're not willing to try to put your money where your mouth is, then please shut up. Except, when Matt Dillon did submit, he was told to back out his changes and then lost his commit bit. This was because there was an imminent commit due from somebody working on SMP, which still isn't finished really. I have the greatest respect for Matt, but he has been a serious problem for the project for a long time. His technical disagreements with other members of the project are just one relatively minor aspect of those problems. His personality has been a much bigger issue. In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. Who cares about users? This is their project after all. If you want to feel like this is your project, then you need to find a way to take ownership of some part. See above. Personally, unless the madness around SMP, the 5- branch and various other bits are ironed out, I can see my next server deployment making use of DragonFly. Please let us know how it turns out. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Wes Peters said: [Charset iso-8859-1 unsupported, filtering to ASCII...] On Monday 05 January 2004 11:14 am, Brett Glass wrote: I'd like to see a more open and inclusive form of governance for FreeBSD. The current system of governance has, as its underlying assumption, that the most prolific coders make the best leaders. In my personal experience, this isn't a valid assumption. System administrators and end users have a big stake in FreeBSD, and are just as likely (perhaps more likely) to be good leaders for the project. The current system of governance is open and inclusive of those who have demonstrated the talent, ability, and willingness to be contributors to FreeBSD. The current core team is made up of a mix of big-time coders like Peter and Warner, and small-time coders like myself (now slightly below middle of the pack on commits) and a variety of other skills. ... Somebody whose viewpoint doesn't extend beyond the virtual memory system, for instance, may be critical to the success of a kernel, but that doesn't necessarily make them the best person to steer a complex product that brings 10,000 applications along with it. It is INTERESTING to comment on someone whose viewpoint doesn't extend beyond the VM system, because out of Greenman, me and even Matt Dillon, (and the extremely respected alc), I don't know of any people with a myopic VM viewpoint. An example of that might be Matts ability and succes dealing with the VERY IMPORTANT NFS issues, or perhaps my implementation of the vfs_bio merged cache, minimal-copy pipe code, kernel memory management improvements (which aren't really VM per se), early playing with the ATA driver, SIGNIFICANT filesystem work (e.g. the vastly improved LFS didnt' get installed because of softupdates making it redundant), careful rework of certain portions of low level code, and it is definitely ludicrous to claim that Greenman was VM myopic. The biggest problem that I currently see on the technical side has NOTHING to do with the individual competencies, but the SMP locking complexity issues that I had predicted would happen. By looking at the locking from the VFS, VM, IPC and hardware standpoints (I admittedly wasn't and STILL AM NOT competent on networking issues), it is very very clear that restructuring the system to support more coherent and orderly locking would make the system INFINITELY more maintainable. It might even be worthwhile to start a rearchitecting now, recognizing that there were important things learned during the current exercise. The VFS and VM systems have numerous interdependencies, due to the very desired specified coherency, desired modularity and natural control/data flow. EVEN THOUGH it is very possible to make superficial modifications to the traditional structure in order to support adequate SMP locking, the design will likely become unmaintainable for future improvements or restructuring, the structure will be susceptable to bit rot. The VFS, VM and scheduling mechanisms could have (with nominal effort) been upgraded to use more of a realtime kernel structure (while retaining the timesharing behavior when desirable.) Using tsleep or its derivatives for process blocking with control/data stack context being intermingled with sundry data structure (and subsystem) locks make for a design that will sustain a high priesthood for years. (A wonderful side-effect of breaking the tsleep/stack marriage, is that VFS layering can be much easier decoupled from the VM and VFS interaction and coherency issues.) This should also have positive consequences WRT network stack state... Perhaps a good first step would have been to progressively remove the dependency upon stack context during thread/process blocking. This has several interesting positive side effects... However, this definitely breaks from the sleep/wakeup paradigm. There are numerous ways to break the dependency on the stack context, and I am partial to using continuations along with a few other possible paradigms. I haven't looked into these issues for years, but there might be some schemes that are even more effective or architecturally 'clean.' All this said, I still think that FreeBSD is the best choice for a general purpose OS. It is good that the system still works smoothly under load (something that I tirelessly strived for), making sure that during heavy loading conditions that system latencies (while waiting on various internal resources) are minimized. FreeBSD is proof that system caching doesnt' have to be continually manually tuned for any normal configuration... John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Who's the troll? (was: Where is FreeBSD going?)
Paul Robinson wrote: All I'm suggesting (and no, I'm not the troll, but I'd thank him, whoever he is), I would not thank the troll -- anyone with legitimate concerns can air them under their own names (like you did), otherwise they don't deserve to be taken seriously. That said, I have a bigger concern. Let me point you to this mail from a year ago on the troll's identity: http://docs.freebsd.org/cgi/mid.cgi?29127.1044803212 where Poul-Henning Kamp claims (in rather abusive terms) that the troll was Bill Huey. In reply to doubts raised by me, http://docs.freebsd.org/cgi/mid.cgi?20030209181722.GA19704 Mark Murray replied that he admitted to it: http://docs.freebsd.org/cgi/mid.cgi?200302091826.h19IQBaX035066 Now you can argue that PHK is a private individual who speaks only for himself. But Mark Murray is a core member and presumably takes responsibility for what he writes, so I saw no reason to disbelieve him back then, though it did not fit BillH's pattern at all. Recently however in private mail to me, BillH denied it totally and added that he has denied it in private mail to FreeBSD people too, but it refuses to die down. I don't have a position since I know nobody personally. But such unsupported public accusations against someone's character are a very troubling matter. So will Mark and PHK either supply the proof, or retract the claim? Why accuse BillH anyway? In fact, he had recently annoyed the powers that be. He had exploded in violent language on the lists, after what he saw as a slight to him over the FreeBSD Java project, to which he had contributed immensely -- check the archives. His grievance may have been legitimate, but I don't condone the language he used; but the point is that he did it all in his own name, whereas the troll is clearly embarrassed to reveal his identity. Anyway, to an outsider like me, it seems possible that someone decided to get even with BillH by accusing him in this way. I'm not saying that's the case, but you must admit that it's a fair conclusion to jump to, and make amends for it. Or else, any of us could be next, simply on the grounds that someone in the FreeBSD hierarchy doesn't like us. - Rahul (NOTE: I exchanged some private mail with Bill Huey, and checked with him that it's ok to mail the list, but this mail is from me, not from him.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
The only thing any of the committers cares about is what they think. Got a problem? Submit a patch. Don't like the way things are done? Submit a patch. Don't like how such-and-such a util works? Submit a patch. Please suggest an alternative, given that almost all the labor is volunteer labor. There are hundreds of PRs still to be processed that do have patches -- in fact, on most days the backlog is getting bigger, not smaller. IMHO it's reasonable to prioritize concrete suggestions over wish-list items. What else should we be doing? Except, when Matt Dillon did submit, he was told to back out his changes This had more to do with personalities than technology. Other people have had patches rejected, backouts requested, and in some cases, backouts forced upon them. Many of those people are still with the project. In a cooperative anarchy, things are never going to be perfect; further, I think it's unfair to generalize this one situation to saying this or that contribution doesn't count. This was the culminating incident of a long-standing clash between strong personalities. It's too bad that it worked out the way it did, but I think other than that it's not useful to make generalizations from this one controversy. In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. What you may be interpreting as resentment may actually just be frustration at being once again in the middle of being told things are broken without concrete suggestions about how it can be fixed. Please come up with some kind of definite proposal that you think would alleviate your, and others', concerns; and post it and let us discuss it. Keep in mind that as you do so it's a volunteer project, and you have to address the interests of the current volunteers too. Perhaps you can suggest a way to bring more volunteers in without losing any of the existing ones. I certainly don't have any answers to these kinds of questions; let me take a look at yours. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Tue, Jan 06, 2004 at 08:52:37PM +, Colin Percival wrote: At 20:31 06/01/2004, Mark Linimon wrote: There are hundreds of PRs still to be processed that do have patches -- in fact, on most days the backlog is getting bigger, not smaller. Speaking of which... if there's one thing which could be done to improve committer / non-committer relations, it would be to *do* something with all those PRs. The ports team is pretty good -- my maintainer updates have always been committed fairly quickly -- but I've never had a src patch committed without badgering committer(s) about my PRs. Hm, it is one of the weak spots for sure. Not much different from paid-for development work, most people I've ever met working in that area tried to avoid doing maintenance work aka bug fixing. 2nd to avoiding maintenance work is not writing documentation if at all possible :) Not an excuse, just an observation. W/ -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Who's the troll?
Dag-Erling Smørgrav wrote: Rahul Siddharthan [EMAIL PROTECTED] writes: [is Bill Huey the troll?] Does anybody seriously believe this? Mark Murray, a FreeBSD core team member, publicly said this on an archived and searchable mailing list. That's my problem with it. Nobody cares what random people may have said to one another on IRC, but when someone who can be regarded as a spokesman for the project puts it on record, it's significant. For my part, while I don't particularly like Bill Huey, I have no reason to believe that he is the troll, and a couple of good reasons to believe that he isn't: And I agree totally with all your reasons for believing he isn't. Rahul ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
reading raw data from a CD-R with damaged table of contents
Hi all, I added some files to a multisession CD-R with the burncd command. It appeared to work fine, but when I read the disk, the new files didn't show up. So I did the burncd fixate command - bad idea! Now nothing shows up! (burncd's no Nero Burning Rom! Live and learn... Is the GUI burning software usable and reliable?) I assume it just destroyed the table of contents. Any suggestions for how I can recover that data? I couldn't find software to read raw data from anything. Do you guys know of anything? I would have to write something myself would I? Do you know where I can find an ISO 9660 filesystem specification? This is possible, right? Thanks, Kevin __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 11:28 PM + 2004/01/06, Paul Robinson wrote: Accepted. It came from [EMAIL PROTECTED] and therefore can only represent my own opinion. In the future, may I suggest that you make this sort of statement more clear at the beginning? It sounded to me like you were standing up as a self-appointed champion of the rest of the world. But I know a lot of people who are looking at deploying 5- who aren't just pissed off - they're *scared*. FreeBSD-5 was always going to be problematical. There have probably been more things changed for this major version than for any previous major version in history, maybe even for all previous major versions combined. They bit off a great big honking whackload with this version, and they knew it. That's why we're so far behind the original release timetable (one year? two years?). Any reasonable production-oriented plan would have been to stick with 4.x until such time as 5.x has been declared STABLE, and then wait for another minor release or two after that. Timetables can (and do) slip, so you'd have to build that into the picture. I don't think many of the developers understand this. My personal opinion is that I believe many of them understand this better than you know. See above. To us (yes, I'm not speaking for Brad Knowles), FreeBSD is not a project we spend our spare time on and love and adore. Well, it is, but it's also a lot more. It defines our careers. We roll out something that isn't quite right, our jobs are finished. I've been there. I was the only FreeBSD guy bringing in machines into the largest ISP in Belgium, where everyone else was a Linux fanatic. They learned to respect the machines I brought in and how rock-solid they were, and my co-workers have since taken over and rolled out even more FreeBSD servers since I left. I believe they have the largest USENET news servers in the country, and the machines are also some of the most robust in the facility. Right now, if somebody asks me what our roll-out strategy is for the next 18 months, I have to respond don't know, whereas the Linux guys are just laughing... don't even start me on what the Windows guys are doing to my career right now See above. Roll out 4.x for now, wait for 5.x to stabilize. That should have been the plan since 5.x first became -CURRENT years ago. The Linux guys have a lot to deal with, too. Red Hat licensing is now looking nearly as expensive as Sun, Mandrake is bankrupt, SuSE is being bought by Novell (in preparation to kill it?), and who else is left? They've always had a schizophrenic situation, with the dichotomy between the kernel developers versus the distribution creators. Windows? Well, Longhorn just got pushed out yet another year -- wait until 2005 or 2006, at least. Nothing to worry about there. OK, so it has got personal... I accept it is not the FreeBSD development team's job to look after my career, and to date I've looked after that by myself OK, but all I'm asking is you try and at least understand where some people are coming from on this. I understand, and I believe that the vast majority of the FreeBSD developers understand. Mark has mailed me off-list. His tone isn't great. I probably deserve the Fuck off. Go away. I'l deal with that seperately. :-) In my original draft of my response, I basically told you to STFU myself. I decided that discretion was the better part of valor, and toned down that remark. But I can certainly understand the frustration resulting from having seen your post. OK, I've never run into that. Over on the DragonFly stuff, he seems pleasant enough and his ideas are innovative, strong, if sometimes... *cough*... eccentric (e.g. replacing sysinstall with an Apache server and a load of PHP...), but I'll accept I haven't seen that, and I know others have had their problems there. Well, since it's his project, I'm sure he feels a lot more secure. Perhaps he's taken some lessons from previous mistakes with the FreeBSD project, and he's working to avoid re-living them with DragonFly. I did see the fall-out on these lists with the argument that caused it all to kick off about a year ago though, and I don't think others on the project dealt with him (in public at least) fairly. Again, just my opinion, I wasn't involved, don't know what happened in private. I don't think that we saw more than the slightest bit of what really happened. I will agree that I think this matter could have (and should have) been better handled with regards to the public aspects, but anyone who was watching the lists at the time should have noted that this was not a new type of problem, and there were multiple references to previous situations of a similar nature. Ooooh, no. That isn't what I want at all. I just want end-users to feel they have a voice. That's all. Maybe they
Re: reading raw data from a CD-R with damaged table of contents
It seems Kevin Serwick wrote: Hi all, I added some files to a multisession CD-R with the burncd command. It appeared to work fine, but when I read the disk, the new files didn't show up. So I did the burncd fixate command - bad idea! Now nothing shows up! (burncd's no Nero Burning Rom! Live and learn... Is the GUI burning software usable and reliable?) I assume it just destroyed the table of contents. Rather you add a new one that is empty or garbled. Any suggestions for how I can recover that data? It might be posible to read the original session, I seem to remember that it can be set somehow, but default is to always read the last. However its been quite a few moons since I last looked in the color books. I couldn't find software to read raw data from anything. Do you guys know of anything? I would have to write something myself would I? Possibly, it might be as simple as modifying the atapi-cd.c driver to be able to read a specific session, see above... Do you know where I can find an ISO 9660 filesystem specification? Uhm ETSI has some of them for free IIRC.. This is possible, right? Probably, I always feel very much at risk when saying the opposite :) -Søren Yes I know it works under windows!! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Paul Robinson writes: In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. 4. In private I've already apologised for that particualr comment as I realise now it was very Daily Mail of me to make it (for those of you without access to the Daily Mail, congratualations), and it's only fair as it spilled out onto the public lists, that I apologise here too. Mark also apologised for swearing at me. I consider hands to have been shaken over this. :-). And for those of you who normally shout Submit a patch - well, I'm thinking about it. :-) I've been thinking of your objection to the submit a patch reply, and I offer this as a proto-thought on how it can be applied to non-coders: As FreeBSD is a volunteer project, I suspect part of the problem is getting said volunteers to do things that they would otherwise not do. Submit a patch can be easily(?) extendted to cover a much wider area of volunteer-organised work than simply code. Under specifically _patches_, there are code, documentation and web page patches, but there is also a need for organizational skills. The PR database frequently gets blitzed by keen folks who get lots of PRs closed, follwed by burnout. We are doing rather well with our release-engineering team (Go Scott L!), and our currently active admin@ crowd are doing a great job, but we could still use skills, and these are not necessarily of the coding kind. SO - instead of submit a patch perhaps if we were to go submit something tangible and useful? This can be anything that will forward the progress of FreeBSD. It could be something lofty like paying the salary of a developer who will then work primarily on projects useful to yourself. It could be commissioned work for a particular project you would like to see done. It could be a financial or equipment donation. It could be a donation of your time in a way that would be useful (please help here by finding something that needs doing and offering to do it, rather than expecting us geeks to find it for you!). It could be _anything_ that forwards the aims of the project and that you can do, and it preferably needs to be something that can be done autonomously (or as autonomously as possible). You will not get paid, you may not get thanked, but you will have the satisfaction of actually getting something done, and if you like FreeBSD as much as I do, that is an end in itself! M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Hi, Time to force use of gnupg or something like that to prevent this to happen. Just an opinion. Yours, Nuno Teixeira On Tue, Jan 06, 2004 at 02:52:58PM +0100, Maxime Henrion wrote: Hi all, Since several people actually thought this mail was written by me, I'm replying here to tell it wasn't. This mail was sent by the same guy who periodically impersonate one of the FreeBSD committers to rant about the project. His mail doesn't reflect my thoughts at all. Please all let this thread die. Thanks, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Nuno Teixeira SDF Public Access UNIX System - http://sdf.lonestar.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
In a message written on Wed, Jan 07, 2004 at 02:09:33AM +0100, Brad Knowles wrote: FreeBSD-5 was always going to be problematical. There have probably been more things changed for this major version than for any previous major version in history, maybe even for all previous major versions combined. They bit off a great big honking whackload with this version, and they knew it. That's why we're so far behind the original release timetable (one year? two years?). Any reasonable production-oriented plan would have been to stick with 4.x until such time as 5.x has been declared STABLE, and then wait for another minor release or two after that. Timetables can (and do) slip, so you'd have to build that into the picture. Speaking with a user hat on, I'll comment on what I believe is the crux of the 5.x issue. You are 100% right, in that all documentation, communication from FreeBSD developers and soforth has pointed to remain on 4.x for production machines until 5.x has a stable release, and that it will be a while. From a practical point of view that has been rapidly breaking down over the last 6-12 months. People need features in 5.x. Various people have decided (for good reason, I'm not questioning the decisions) that a large number of features go into 5.x, and because of the difficulty in back porting don't go into 4.x. Indeed, the only reason I'm running -current now is I need support for an Atheros wireless card. The take away I see is that this was too big of a chunk. The next bite planned needs to be smaller. You can't delay one year or two years in a production environment. New hardware needs drivers in that time. New protocols become production deployed in that time. I am also a firm believer that having all the developers focused so much on meeting deadlines for all this new complexity leaves them out of time to deal with the PR's that have been piling up. For FreeBSD to appeal to the masses it must install on the latest and greatest Dell or Gateway or whatever, which means it must include drivers for today's cheaper-by-the-gross parts from China. Driver updates in particular need to be very regular, and in the active -STABLE release, which for now means back-ported to 4.x, even if that means a complete rewrite because of how different the kernels are. Otherwise people get forced to run 5.x for a few driver issues, and then complain like crazy about all the other stuff that's not ready for prime time. Mom said it best, small bites, chew with your mouth closed. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
In a message written on Wed, Jan 07, 2004 at 10:22:44AM -0500, Lanny Baron wrote: Just what we are wondering. Where is all the FreeBSD community support for a Server company that fully supports FreeBSD? It certainly is not in this letter. Disclaimer: Until this message I didn't know www.FreeBSDsystems.com existed, and I know nothing about them other than what the front page of their web server has on it. I believe you've missed the point completely. Building a new server farm is an important, but specialized niche. Sure I can buy hardware that is only 100% fully supported. I may have to pay a little more, but to some degree that's ok. The point is that the person trying FreeBSD at home (where Linux is a competitor), or wanting to put it on their desktop at work (where IT just gave them a PC with windows, and the boss will let them run FreeBSD, but won't buy yet another PC to do it) suffer. OS's like FreeBSD and Linux make their way into the enterprise from the ground up, running on the old leftover box in the corner. So, do I support companies like (but not specifically) www.freebsdsystems.com, sure. Does that mean the freebsd development team can forget about all the other hardware out there in massive quantities, heck no. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
On Wed, 7 Jan 2004, Leo Bicknell wrote: From a practical point of view that has been rapidly breaking down over the last 6-12 months. People need features in 5.x. Various people have decided (for good reason, I'm not questioning the decisions) that a large number of features go into 5.x, and because of the difficulty in back porting don't go into 4.x. Indeed, the only reason I'm running -current now is I need support for an Atheros wireless card. The take away I see is that this was too big of a chunk. The next bite planned needs to be smaller. You can't delay one year or two years in a production environment. New hardware needs drivers in that time. New protocols become production deployed in that time. I am also a firm believer that having all the developers focused so much on meeting deadlines for all this new complexity leaves them out of time to deal with the PR's that have been piling up. My perspective as a developer is that there were a lot of things in FreeBSD that needed an overhaul. SMP for example. Sure, it's not perfect and probably still has a ways to go, but this touched a lot of things. I fully expected FreeBSD-5 to get worse before it got better, perhaps lose some folks to Linux because they couldn't wait for stable -5 features. Could it have been better managed? Sure, in a better world where we had more of our developers getting paid to do this (we're lucky that we still have a handful or two of them). For FreeBSD to appeal to the masses it must install on the latest and greatest Dell or Gateway or whatever, which means it must include drivers for today's cheaper-by-the-gross parts from China. Driver updates in particular need to be very regular, and in the active -STABLE release, which for now means back-ported to 4.x, even if that means a complete rewrite because of how different the kernels are. Otherwise people get forced to run 5.x for a few driver issues, and then complain like crazy about all the other stuff that's not ready for prime time. Mom said it best, small bites, chew with your mouth closed. I understand this position, but I think this step was a necessary one for the future of the project. My $.02. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: switching between groups
Unfortunately, newgrp(1) would not work, because it calls setgroups, which for some weird reason, needs the caller to be a superuser. Isn't there a function that sets the groups (like setgroups) of the current process where you don't have to be a superuser? To maintain security, that function could just check that the groups being set by setgroups are a subset of the caller's set. Does a function like that already exist? If not, how come? Thanks, Adil -Original Message- From: Bruce M Simpson [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 1:12 PM To: Adil Katchi Cc: '[EMAIL PROTECTED]' Subject: Re: switching between groups On Tue, Jan 06, 2004 at 11:14:06AM -0500, Adil Katchi wrote: I was just wondering if anyone has any ideas how it's possible for a user that belongs to multiple groups to somehow limit his or her own capabilities by using only one of the n groups that they belong to and be able to switch between these groups? For example, if userA belongs to groupA, groupB and groupC, can userA enter a mode that would force it to only belong to groupA (or groupB, or groupC)? UserA whould be able to switch between these groups and back to normal (ie. belong to all groups). newgrp(1) could be hacked to do this fairly easily. Currently it preserves supplemental group memberships. An option to discard supplementals could be added. Or just call setgroups() with a no-op group-list vector and then setgid()/ setegid() from within your application. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
Hi, Leo Bicknell wrote: [snip] For FreeBSD to appeal to the masses it must install on the latest and greatest Dell or Gateway or whatever, which means it must include drivers for today's cheaper-by-the-gross parts from China. Driver updates in particular need to be very regular, and in the active -STABLE release, which for now means back-ported to 4.x, even if that means a complete rewrite because of how different the kernels are. Otherwise people get forced to run 5.x for a few driver issues, and then complain like crazy about all the other stuff that's not ready for prime time. Just what we are wondering. Where is all the FreeBSD community support for a Server company that fully supports FreeBSD? It certainly is not in this letter. As for the parts from China part, we don't buy any 'cheaper by anything' components. We don't look for a way to sell 'cheap servers'. We soley build that which runs extremely well on our Servers with FreeBSD 4.x or 5.x on it. When I read about people who buy Servers from the major players the large computer companies such as those listed above and who by the way, don't give a flying *#@ about FreeBSD, I wonder why the principles here continue to be loyal to the FreeBSD community. Mom said it best, small bites, chew with your mouth closed. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Lanny Baron Proud to be 100% FreeBSD http://www.FreeBSDsystems.COM Toll Free: 1.877.963.1900 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
# [EMAIL PROTECTED] / 2004-01-07 14:29:35 +: Paul Robinson writes: And for those of you who normally shout Submit a patch - well, I'm thinking about it. :-) I've been thinking of your objection to the submit a patch reply, and I offer this as a proto-thought on how it can be applied to non-coders: As FreeBSD is a volunteer project, I suspect part of the problem is getting said volunteers to do things that they would otherwise not do. Submit a patch can be easily(?) extendted to cover a much wider area of volunteer-organised work than simply code. Under specifically _patches_, there are code, documentation and web page patches, but there is also a need for organizational skills. The PR database frequently gets blitzed by keen folks who get lots of PRs closed, follwed by burnout. We are doing rather well with our release-engineering team (Go Scott L!), and our currently active admin@ crowd are doing a great job, but we could still use skills, and these are not necessarily of the coding kind. Help us (users, port maintainers and random porters w/o commit) help you (committers). There are two areas I can (and do in one of them) participate: ports and documentation. Activities in both areas result in patches, and those need a committer. PRs need more hands, more people who can commit stuff. Quite a few port maintainers could have commit, even limited to just parts of the ports tree (IOW just their ports). The ports freeze seems to last too long with recent releses. Or maybe it's just I've gotten more involved, but out of the last four months (2003/09/07-today), ports tree has been completely open for whopping 28 days. Limitations of CVS don't exactly help either. The fact that you need direct access to the repository to be able to copy a tree with history (repocopy) as opposed to this operation being part of the interface[1], which means being lucky enough to find a committer, and get them commit the stuff within the blink of an eye ports is open, further constrains people's ability to work on FreeBSD with some satisfaction. While minor stuff can be managed by keeping multiple working copies, thorough documentation (or just any, really) on setting up local cvs mirror and using $CVS_LOCAL_BRANCH_NUM is sorely missing; or did I get it right quite recently that this is discouraged because of software issues (ISTR it was jdp@ who said it)? Porter's handbook, and FDP Primer, while valuable (esp. the former) leave many questions unanswered. (I'm not going to further this rant, but will gladly provide feedback to anyone who asks.) [1] has core@ considered subversion (devel/subversion)? -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, 7 Jan 2004, Roman Neuhauser wrote: [1] has core@ considered subversion (devel/subversion)? Everyone has their eyes wide open looking for a revision control alternative, but last time it was discussed in detail (a few months ago?) it seemed there still wasn't a viable alternative. On the src tree side, FreeBSD committers are making extensive use of a Perforce repository (which supports lightweight branching, etc, etc), but there's a strong desire to maintain the base system on a purely open source revision control system, and migrating your data is no lightweight proposition. Likewise, you really want to trust your data only to tried and true solutions, I think -- we want to build an OS, not a version control system, if at all possible :-). Subversion seems to be the current favorite to keep an eye on, but the public release seemed not to have realized the promise of the design (i.e., no three-way merges, etc). You can peruse the FreeBSD Perforce repository via the web using http://perforce.FreeBSD.org/ -- it contains a lot of personal and small project sandboxes that might be of interest. For example, we do all the primary TrustedBSD development in Perforce before merging it to the main CVS repository. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: switching between groups
On Wed, 7 Jan 2004, Adil Katchi wrote: Unfortunately, newgrp(1) would not work, because it calls setgroups, which for some weird reason, needs the caller to be a superuser. Isn't there a function that sets the groups (like setgroups) of the current process where you don't have to be a superuser? To maintain security, that function could just check that the groups being set by setgroups are a subset of the caller's set. Does a function like that already exist? If not, how come? Groups are sometimes used for negative access control rights: i.e., permissions are set on a file so that users who should not be able to read the file are in a group, and the group rights are less than the 'other' rights. If users can drop arbitrary groups, they can leave the group excluding the rights. This probleis more or less pronounced with ACLs, depending on who you speak to: using negative rights is often a workaround for not having ACLs, but with ACLs, you can add more than one group to a file, and don't have to be a member of the group to add it... It does strike me that newgrp(1) seems less than useful without the setuid bit... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research Thanks, Adil -Original Message- From: Bruce M Simpson [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 1:12 PM To: Adil Katchi Cc: '[EMAIL PROTECTED]' Subject: Re: switching between groups On Tue, Jan 06, 2004 at 11:14:06AM -0500, Adil Katchi wrote: I was just wondering if anyone has any ideas how it's possible for a user that belongs to multiple groups to somehow limit his or her own capabilities by using only one of the n groups that they belong to and be able to switch between these groups? For example, if userA belongs to groupA, groupB and groupC, can userA enter a mode that would force it to only belong to groupA (or groupB, or groupC)? UserA whould be able to switch between these groups and back to normal (ie. belong to all groups). newgrp(1) could be hacked to do this fairly easily. Currently it preserves supplemental group memberships. An option to discard supplementals could be added. Or just call setgroups() with a no-op group-list vector and then setgid()/ setegid() from within your application. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 12:42 PM +0100 1/7/04, Dag-Erling Smørgrav wrote: Paul Robinson [EMAIL PROTECTED] writes: If 5.3, when it arrives, is genuinely production ready, trust me, the drinks are on me - I will do my absolute best to get to the next BSDcon and get everybody drunk on an expense account. If it isn't, well, I'll just have to whisper I told you so quietly somewhere. I am currently working for an ISP whose infrastructure is based 75% on FreeBSD 5.1. ... I am about to start in a new job... I asked them what it was like to develop on -CURRENT compared to -STABLE. Their answer: a relief. I would add that I've been running almost exclusively on 5.x for over a year now (except for one machine which I have not rebooted in over a year...). There have been some *very* painful transitions at various times, but once I get past the transitions the system has been quite stable. (fwiw, in my case, I am only running on desktop systems). So, once we stop making major API/ABI changes and the branch is truly stable (with a 6.x branch for new cutting-edge developments), I personally am quite confident that 5.x will be a stable, production-quality system. And there are a number of features in 5.x that I think are tremendous advantages -- especially for boxes in a production setting. My guess is you're going to have a large bar tab at the next BSDcon... Certainly I hope so! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
:It is INTERESTING to comment on someone whose viewpoint doesn't extend :beyond the VM system, because out of Greenman, me and even Matt Dillon, :(and the extremely respected alc), I don't know of any people :with a myopic VM viewpoint. An example of that might be Matts ability :and succes dealing with the VERY IMPORTANT NFS issues, or perhaps my implementation :of the vfs_bio merged cache, minimal-copy pipe code, kernel memory management :improvements (which aren't really VM per se), early playing with the ATA :driver, SIGNIFICANT filesystem work (e.g. the vastly improved LFS didnt' :get installed because of softupdates making it redundant), careful rework of :certain portions of low level code, and it is definitely ludicrous :to claim that Greenman was VM myopic. Currently in FreeBSD-5 there are far fewer people able to work on a wide range of subsystems due to the complexity of the SMP environment. That should be clearly obvious to everyone... I rarely see cross-disciplinary commits (though there are other reasons for that observation beyond the complexity of the SMP environment). Certainly I see far fewer such commits then occured in the 4.x days. Focus is good, but the complexity of the APIs are such that as some of the current developers move on to other things large swaths of code are going to start to become unattended through lack of understanding, and it could potentially swamp the relatively few interdisciplinary people left in the project. The SMP interactions that John mentions are not trivial... they would challenge *ME* and regardless of what people think about my social mores I think most people would agree that I am a pretty good programmer. I have no doubt that FreeBSD-5 can be stabilized with the current development crew, but the warning signs abound and if the SMP environmental interfaces are not simplified FreeBSD-5 will end up in serious trouble down the line. The idea (that some people have stated in later followups to this thread) that the APIs themselves will stabilize is a pipedream. The codebase may become reasonably stable, but there are a lot of things in there that people are going to want to rewrite in coming years, and rewriting by people other then the original authors is one of the reasons why we had so much trouble in the 2.x and 3.x days. Look at how little VFS has been touched in the intervening years despite the fact that it is obvious that it has needed a serious rewrite for the last decade. I can barely figure it out even now and I have spent hundreds of hours working on VFS. I mean, I don't think anyone can honestly say that the scheduler is 'done', or even close to done. Look at how long the original 42 scheduler was worked on after it was originally finished? Same goes for the VM system, VFS, the slab allocator, the mutex related code, the USB code (EHCI for example), and everything else. Simplifying maintainance should be of paramount concern to everyone, and the number one most complex issue in FreeBSD-5 right now are the SMP related APIs and non-deterministic scheduler side effects like preemptive cpu migration, indirect preemptive switching to non-interrupt threads due to priority borrowing, and non deterministic side effects from blocking in a mutex (because mutexes are used for many things now that spl's were used for before, this is a very serious issue). See? I didn't mention DragonFly even once! Ooops, I didn't mention DFly twice. oops! Well, I didn't mention it more then twice anyway. -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 9:57 AM -0500 1/7/04, Leo Bicknell wrote: Speaking with a user hat on, I'll comment on what I believe is the crux of the 5.x issue. The take away I see is that this was too big of a chunk. The next bite planned needs to be smaller. I agree with this observation, but then it's easy to see that in hindsight. We started on some ambitious targets when 5.x started, and at the time we believed we were going to have a lot more full- time development resources than we ended up with. That whole big problem with the dot.com bubble bursting. I do think we need to tackle a somewhat smaller chunk of projects for 6.0, so it won't take so long to get it done. I also expect we have a much more realistic idea of what our resources are than we had in late 1999. You can't delay one year or two years in a production environment. Actually, in a production environment you're more than happy to delay a year or two. You don't want constant churn. You don't want new API's and ABI's every year. The problem for freebsd is that 4.0 was released in March of 2000, and that was advertised as a stable release. 5.0 was released in January of 2003 -- and was explicitly *not* a stable release. We could stand to have a major stable release every two years, or maybe even every three years, but this is going to be more like four years. That is too long. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
On Wed, 2004-01-07 at 20:29, Nick Rogness wrote: 1) Allow for paid development for a specific bug/feature - Setup some program that allows users like myself to pay for a developers time to fix a specific bug. The company I work for would easily pay serious dollars to fix our SMP problems with 4.X. Unfortunetly, getting someone's attention that has a great understanding of the OS is hard to find without rude remarks and what-not. You could even extend it as far as saying we will promote this PR to the top of the list of tasks if you pay us XX dollars. Or maybe, the more you pay the higher you go. This would reassure the user base that things CAN get done if needed and also let the developer/bug fixer feel like they can make money and have some fun. It will also bring in money for the project as part of that money could go back into the Project. You could easily setup a pool mailling list (like -requests) which someone like myself would email a request with the problem description (or PR). If a developer is interested in tackling the problem for money, we could privately negotiate a price. The same can be done for driver development and others. Make it a Donation for a specific request. I don't want to give money to some Foundation where money can be thrown around in the wrong areas. I want to pay the developer personally for their efforts. ( I feel the same should be done with our taxes as well ;-) I really don't like the idea of making this a policy, or even some official part of the project. I think this might discourage some from contributing in hopes to be paid for it. I think a better solution for companies looking for this would be to post to the jobs@ mailing list noting that it is a temp job. I don't think giving priority to paying entities is a path the project should tread down. If someone needs FreeBSD developer work they should look for someone to hire. Something like this might also jeopardize the project's not for profit status. I think the jobs@ mailing list would be a better start. (I'm going to be looking for a full time job in about 11 months and if I got one where I got to code/administer BSD I'd feel I was in Heaven.) :-) 2) Setup a mailling list for just new developer questions. This would be a great idea, however, it might be something the hackers@ list was originally intended for. Unfortunately I think no matter what list you create there will always be those feelings and people that will speak like that. People just have to remember that although it may sound as if someone is ridiculing them it might not be there intention. The Internet is a rather flat medium for communicating emotion. 3) Simple but time consuming requests from developers - Isn't it possible to have developers pass off some of their simple tasks to others? Think of it like a pet dog. Your dog may be able fetch your newspaper but he couldn't read it. Still fetching the newspaper takes time! The requests I see are usually Jr. kernel type requests. Everyone wants to contribute at the kernel level but that takes a lot of knowhow and experience working with fbsd's kernel. Let users get involved with simple (stupid) tasks which are time consuming. Now define simple... Again, I think a JKH (Junior Kernel Hacker) list (like the one PHK had for awhile) would be a great addition. I'll even volunteer to maintain it if developers were willing to help me by providing these small projects for people to work on. As someone attempting to join the ranks of people in the Submitted by: log lines this is one of the hardest things for me to do is find something I can work on. I think this might be some duplication of the PR database; some PRs are things that could be accomplished without too much skill. I think the trouble though is wading through to find these specific issues. Perhaps such a list could contain cross-references to the PR db. -- Ryan Sommers [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
3) Simple but time consuming requests from developers - Isn't it possible to have developers pass off some of their simple tasks to others? Think of it like a pet dog. Your dog may be able fetch your newspaper but he couldn't read it. Still fetching the newspaper takes time! The requests I see are usually Jr. kernel type requests. Everyone wants to contribute at the kernel level but that takes a lot of knowhow and experience working with fbsd's kernel. Let users get involved with simple (stupid) tasks which are time consuming. Now define simple... Again, I think a JKH (Junior Kernel Hacker) list (like the one PHK had for awhile) would be a great addition. I'll even volunteer to maintain it if developers were willing to help me by providing these small projects for people to work on. As someone attempting to join the ranks of people in the Submitted by: log lines this is one of the hardest things for me to do is find something I can work on. The only problem with a JKH list is that there need to be committers willing to review and commit PRs that are created from the tasks on the list. About a year ago I started working on one of PHK's tasks, opened up 4 PRs, and found absolutely nobody willing to review or commit them. After a month of pinging people and waiting for feedback (and getting absolutely none), I just stopped working on it. It's these kinds of impasses that prevent people who have the skills and time from actually contributing to the project. There really isn't any use opening PRs and creating patches if they're never going to get committed (or by the time someone decides to commit them, the patches need to be moved forward 3 or 4 releases.) -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Adaptec 1210SA SATA RAID - need help
Hi, I have this problem with an Adaptec 1210SA S-ATA RAID controller... I want to install FreeBSD 5.1 but it doesn't work with the controller. 5.1 crashes in sysinstall, when probing for devices. I don't know exactly why, but this happens even if the controller is out of the computer. maybe because it doesn't find any hdd ? ok, I got then 5.2RC2 boot floppies, and this doesn't crash, but still it doesn't identify the raid controller, it see 2 hdd. I installed the base system on one of them, and unfortunatly I cannot boot it. Please help me with any suggestion. I don't really care about the hardware raid, I only wish that i could install and boot from one of the drives. Will JBOD mode help me in any way ? I am waiting for any suggestions... If I can't solve this problem, I will be forced to use linux, or I will leave another person taking care of the server, by installing windows :( Thank you very much. Claudiu Dragalina-Paraipan. e-mail: [EMAIL PROTECTED] --- Xnet scaneaza automat toate mesajele impotriva virusilor folosind RAV AntiVirus. Xnet automatically scans all messages for viruses using RAV AntiVirus. Nota: RAV AntiVirus poate sa nu detecteze toti virusii noi sau toate variantele lor. Va rugam sa luati in considerare ca exista un risc de fiecare data cand deschideti fisiere atasate si ca MobiFon nu este responsabila pentru nici un prejudiciu cauzat de virusi. Disclaimer: RAV AntiVirus may not be able to detect all new viruses and variants. Please be aware that there is a risk involved whenever opening e-mail attachments to your computer and that MobiFon is not responsible for any damages caused by viruses. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ADMtek USB To LAN Converter and HomePNA
hey,
i have one of the above. it's a usb device which connects to a HomePNA
network, with a 10/100Mbps ethernet port as well as a couple of RJ11s for
the HomePNA connection.
my problem is i am unable to utilize this device to connect to the HomePNA
network. upon plugging it in, the console says:
aue0: ADMtek USB To LAN Converter, rev 1.10/1.01, addr 2
aue0: Ethernet address: 00:08:54:d0:5d:2e
miibus1: MII bus on aue0
pnaphy0: Am79c978 HomePNA PHY on miibus1
pnaphy0: HomePNA
ifconfig aue0 response is:
aue0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
ether 00:08:54:d0:5d:2e
media: Ethernet homePNA (none)
i run 'ifconfig aue0 10.1.105.26 netmask 0x media homepna' and the
device then gets to the following:
aue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 10.1.105.26 netmask 0x broadcast 10.1.255.255
ether 00:08:54:d0:5d:2e
media: Ethernet homePNA
status: active
however, i am unable to ping any ip address other than the interface's
address. obviously, no firewalls (ipfw/ipchains/ipf) are being run and
this is on FreeBSD 4.9-STABLE built as of a couple of weeks back.
i've played around with disabling the ethernet PHY on the device with the
following diff to /usr/src/sys/dev/usb/if_aue.c:
--- CUT HERE ---
--- if_aue.c.orgWed Jan 7 20:02:51 2004
+++ if_aue.cWed Jan 7 21:04:06 2004
@@ -434,6 +434,28 @@
#endif
}
+ /*
+* The Am79C978 HomePNA PHY actually contains
+* two transceivers: a 1Mbps HomePNA PHY and a
+* 10Mbps full/half duplex ethernet PHY with
+* NWAY autoneg. However, the HomePNA PHY is
+* not recognized, but the 10/100Mbps PHY is
+* though. This skips over the 10/100Mbps PHY
+* and only activates the 1Mbps HomePNA PHY
+*
+* Modified by Dinesh Nair [EMAIL PROTECTED]
+* Wed Jan 7 20:36:34 MYT 2004
+*
+*/
+ if (sc-aue_info-aue_vid == USB_VENDOR_ADMTEK
+ sc-aue_info-aue_did == USB_PRODUCT_ADMTEK_PEGASUSII) {
+ if (phy == 1)
+ return(0);
+ }
+ /*
+* End of modifications by Dinesh Nair
+*/
+
csr_write_1(sc, AUE_PHY_ADDR, phy);
csr_write_1(sc, AUE_PHY_CTL, reg|AUE_PHYCTL_READ);
--- CUT HERE ---
but to no avail. i've discovered that the ethernet PHY is phy==1, while
the two RJ11 PHYs are 2 and 3.
the ethernet PHY works fine and dandy, and i am able to connect it to my
local switch fine. however, i need to use it for a HomePNA application,
and thus need to HomePNA portion of this to work.
any ideas from anyone who's tried something like this before with some
measure of success ? any media types or mediaopts i should be passing to
ifconfig ?
this setup is used by a broadband provider in kuala lumpur, malaysia and
to date this has been the one barrier which prevents freebsd users from
utilizing their service.
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==+
| for a in past present future; do|
| for b in clients employers associates relatives neighbours pets; do |
| echo The opinions here in no way reflect the opinions of my $a $b. |
| done; done |
+=+
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Wed, Jan 07, 2004 at 11:04:37AM +0100, Daan Vreeken [PA4DAN] wrote: For the device this means having to switch the ROM image with the RAM image which is impossible while running in the specific processor. Thus the processor tells it's core to map RAM into code-space and resets itself. After that the device will apear again with address = 0. The host then needs to set the address, re-read the device descriptor (it has changes, the device now offers endpoints etc), attach a driver. Btw, a reset can be sent down to a usb device from within a driver with this line of code : usb_port_status_t stat; usbd_reset_port(sc-atuwi_udev-myhub, sc-atuwi_udev-powersrc-portno, stat); Im mostly worried about having more than a single device with address 0. You can't do this as long as another device gets initialized. Therefor I thought disabling/enabling the port would be better, but I'm wrong as the result is be the same. For my device driver I have made a small change to the USB Stack and I have introduced the return code USB_ATTACH_NEED_RESET for drivers to tell the USB Stack thee device needs to be re-enumerated. The stack then automatically re-assigns the device it's address, and re-probes for drivers. This way even two seperate drivers could be made : one with the firmware and one with the real driver. Is anyone interrested in a patch maybe? Sounds interesting. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
