Re: [RFC] Rewriting sade(8)
2010/4/7 Andrey V. Elsukov : > On 07.04.2010 21:49, Randi Harper wrote: >> >> Wow. This is awesome. patches? :D > > :) > I'm not ready yet to publish code. I planned to announce this RFC > a bit later, when code will be finished. But Konstantin (kib@) suggested > do it before finishing. > >> I've been working on moving sysinstall from libdisk to libgeom, but >> unfortunately it's a bit more complicated (redoing the way we detect >> devices while I'm at it). I've done a lot of the heavy lifting code, >> but I haven't even started on the GUI parts yet. I'd love to see how >> someone else tackled doing this. I'm particularly interested in #5& >> #7. :) > > Initially i wanted to only modify current sade's code to move it from > libdisk to libgeom. But after several attempts i decided that it will be > easier to rewrite it :) > >> Generally, we try to keep sysinstall's disk tools and sade in sync, so >> I would like to work with you on this and see what we can come up >> with. I'm not entirely sure if #2 is a viable option since we already >> have functions in sysinstall that handle generating dialog boxes with >> libdialog, but if it's an improvement on what's existing, bring it on. > > Yes, I looked at this code in sysinstall and in libdialog. Also I looked > to another console UI libs. The main problem of using external libraries > is that not so easy import them into base system. > > libdialog have several problemls too, imho. > 1. Custom dialogs based on ComposeObj are ugly :) > 2. It supports *only* single-byte characters. Initially I wanted to > write code with message catalogs support. But after several tests > I leaved this idea. Also it seems there is no catgets analog for > wide characters. > > -- > WBR, Andrey V. Elsukov It's great that you want to work on this, but there are other people working in the same area, so keeping your code to yourself for too long makes it very likely that it will never get used. -- randi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Hi, Sorry for taking long to fix. Here is another patch. **But before trying it out, please check rev. of your system.** If you are using r206358 (15:29 UTC Apr. 7) or newer, the driver won't work. If you are using older system, please try this patch. http://projects.nasreddine.com/projects/run/repository/revisions/mips1_fix/show/dev/usb/wlan Only if_run.c is patched since last time. (click file name, then click "download") If you are using r206358 or newer, please give me some time to fix. I'm stating it now. Is your kernel compiled with INVARIANTS option? AK - Original Message > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org > Sent: Tue, April 6, 2010 7:29:16 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > PseudoCylon wrote: > - Original Message > > >> From: Ganbold < > href="mailto:ganb...@gmail.com";>ganb...@gmail.com> >> To: > PseudoCylon < > href="mailto:moonlightak...@yahoo.ca";>moonlightak...@yahoo.ca> >> > Cc: > href="mailto:freebsd-current@freebsd.org";>freebsd-current@freebsd.org >> > Sent: Wed, March 31, 2010 8:08:29 AM >> Subject: Re: CALL for TEST > [HOSTAP] run(4) ralink usb wireless >> >> Does stock run(4) > support hostap mode yet? >> > > No. There > were some bugs and I thought I fixed them. So, I called for test. It seems > the > driver is working on x86, but not on mips. hostap mode should work on your > other > computer with i386. > > I'm still working on patch. It panics where > there wasn't any changes made. Strange... > > Hi, Sorry, it looks like I missed some of your emails. Please > let me know if you need any info from my > side. thanks, Ganbold > > > AK > > __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On 08.04.2010 11:27, Randi Harper wrote: It's great that you want to work on this, but there are other people working in the same area, so keeping your code to yourself for too long makes it very likely that it will never get used. Ok. I put the code here: http://butcher.heavennet.ru/sade/sade-20100408.tgz -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Quoting "Andrey V. Elsukov" (from Thu, 08 Apr 2010 10:51:08 +0400): On 08.04.2010 10:27, Bruce Cran wrote: That's a shame. As long as the source isn't available it's of little interest to me. For anyone who wants to see the bits of code I've got so far, I've created a Google Code project at http://code.google.com/p/gcpart/ . I'm currently trying to figure out how to get the partitioning scheme out of the XML tree, which is why there's no geom code there yet. As soon as I do so, I'll start checking in my effort at the new partitioning application. I just thinking about future of my project. It seems there are several people who worked on the same before. And I have not finished yet only few things from initially planned. After that i can remove any unused code, write some comments and publish it somewhere in perforce. Please consider using SVN instead. A lot more users will be able to check out from there. Also at this time code depends on changes which i made in geom_part.so and which are not yet commited into base system. After code review there can be several ways to go. And I have an interest which way will be for me :) It looks like other people had a look at sysinstall, not at sade. As sysinstall is supposed to be used at installation time, and the intent for sade was to offer the functionality (or more) of the part of sysinstall which is useful after installation (and to prevent admins from using sysinstall after the installation to prevent some unwanted foot-shooting), I do not think that we need to think about a strong lock between sysinstall and sade. If you can enhance sade beyond what sysinstall is able to do, I would say go ahead (note: I committed sade). Bye, Alexander. -- Leela: "He's crude and gross and he treats me like a slave." Fry: "Then dump his one-eyed ass." http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When will we can use ZFS v24?
On 7 April 2010 18:33, Dan Nelson wrote: > In the last episode (Apr 07), krad said: > > On 7 April 2010 05:38, Freddie Cash wrote: > > > On Tue, Apr 6, 2010 at 9:35 PM, lhmwzy wrote: > > > > What's your mean?? > > > > > > See the archives for the freebsd-fs mailing list. There are two > > > separate groups working on getting ZFSv22 added to FreeBSD 9-CURRENT. > > > And there's work ongoing to get ZFSv15 added to FreeBSD 8-STABLE. > > > > > > IOW, just be patient. Good things will come to those who wait. ;) > > > > If you re hankering for dedup you better have a big box as its a complete > > resource hog. From what we have seen on our x4500 filers we need about > > 100gig of ram or l2arc ssd to hold the all the metadata for the 34TB of > > storage, otherwise the system grinds to a halt. > > I wish they had an option for "opportunistic" dedup, where if a block is > already in ARC it can be a dedupe candidate, but it won't look it up in the > DDT if it isn't already in memory. That catches the simple "cp -R dir1 > dir2" cases without blowing up the ARC on DDT blocks that 99.% of the > time don't match. > > -- >Dan Nelson >dnel...@allantgroup.com > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ZFS is still currently in heavy development so it might happen. Having siad that it looks like oracle have totally buggered it up for everyone with their retroactive licenses. I hope the CDL was tight enough that stuff wont have to get pulled from freebsd ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Alexander Leidinger writes: > Please consider using SVN instead. A lot more users will be able to > check out from there. We don't grant non-committers access to the Subversion repo. > It looks like other people had a look at sysinstall, not at sade. As > sysinstall is supposed to be used at installation time, and the intent > for sade was to offer the functionality (or more) of the part of > sysinstall which is useful after installation (and to prevent admins > from using sysinstall after the installation to prevent some unwanted > foot-shooting), I do not think that we need to think about a strong > lock between sysinstall and sade. Yes we do. Otherwise we'll just end up back where we are today, where if you want anything more complicated than a single-disk install you have to drop into the fixit shell and do it manually before running the installation procedure. Anythig that sade can do, we want sysinstall to do as well, and we don't want to implement everything twice. My suggestion is to add a "sysinstall mode" to sade where it operates under certain (minor) constraints and reports what it did in a format that sysinstall can parse, so sysinstall can just fork-exec sade instead of duplicating the code. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On 8 Apr 2010, at 10:05, Dag-Erling Smørgrav wrote: > Alexander Leidinger writes: >> Please consider using SVN instead. A lot more users will be able to >> check out from there. > > We don't grant non-committers access to the Subversion repo. The SVN repo is available to the public via HTTP. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Quoting Dag-Erling Smørgrav (from Thu, 08 Apr 2010 11:05:34 +0200): Alexander Leidinger writes: Please consider using SVN instead. A lot more users will be able to check out from there. We don't grant non-committers access to the Subversion repo. Ooops... seems I misremembered his status. Somehow I associate him with something FreeBSD related. Andrey, did you participate in a GSoC? It looks like other people had a look at sysinstall, not at sade. As sysinstall is supposed to be used at installation time, and the intent for sade was to offer the functionality (or more) of the part of sysinstall which is useful after installation (and to prevent admins from using sysinstall after the installation to prevent some unwanted foot-shooting), I do not think that we need to think about a strong lock between sysinstall and sade. Yes we do. Otherwise we'll just end up back where we are today, where if you want anything more complicated than a single-disk install you have to drop into the fixit shell and do it manually before running the installation procedure. Anythig that sade can do, we want sysinstall to do as well, and we don't want to implement everything twice. From the man page: ---snip--- NOTES The sade utility aims to provide a handy tool for disk management tasks on an already installed system. ---snip--- Disk management tasks contains stuff which exceeds what sysinstall needs to provide. One possible extension is to display content from /etc/dumpdates along with partitions (would be helpful if someone uses dump to make backups and wants to delete a partition, but only if there is a recent backup available). My suggestion is to add a "sysinstall mode" to sade where it operates under certain (minor) constraints and reports what it did in a format that sysinstall can parse, so sysinstall can just fork-exec sade instead of duplicating the code. I think this is more complicated than to refactor the interesting part into a backend with an API which both tools can use. This would also allow someone to write a GUI program (e.g. for PC-BSD). Again, there is no need for a *strong* lock between sysinstall and sade. Both should provide similar features regarding partition and slice handling, but they do not need to share exactly the same interface code. Bye, Alexander. -- Above all else - sky. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On 08.04.2010 11:05, Dag-Erling Smørgrav wrote: > Alexander Leidinger writes: >> Please consider using SVN instead. A lot more users will be able to >> check out from there. > > We don't grant non-committers access to the Subversion repo. > >> It looks like other people had a look at sysinstall, not at sade. As >> sysinstall is supposed to be used at installation time, and the intent >> for sade was to offer the functionality (or more) of the part of >> sysinstall which is useful after installation (and to prevent admins >> from using sysinstall after the installation to prevent some unwanted >> foot-shooting), I do not think that we need to think about a strong >> lock between sysinstall and sade. > > Yes we do. Otherwise we'll just end up back where we are today, where > if you want anything more complicated than a single-disk install you > have to drop into the fixit shell and do it manually before running the > installation procedure. Anythig that sade can do, we want sysinstall to > do as well, and we don't want to implement everything twice. > > My suggestion is to add a "sysinstall mode" to sade where it operates > under certain (minor) constraints and reports what it did in a format > that sysinstall can parse, so sysinstall can just fork-exec sade instead > of duplicating the code. Wouldn't a setup similar to fetch/libfetch do the trick here? Move most of the actual "working payload" of sade into a library, and make sade just a frontend for this? That way poking the sysinstall code to use sade should be easier, and updates will automagically fix both things? //Svein -- +---+--- /"\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. Picture Gallery: https://gallery.stillbilde.net/v/svein/ signature.asc Description: OpenPGP digital signature
Re: [RFC] Rewriting sade(8)
on 08/04/2010 12:05 Dag-Erling Smørgrav said the following: > Alexander Leidinger writes: >> Please consider using SVN instead. A lot more users will be able to >> check out from there. > > We don't grant non-committers access to the Subversion repo. But nothing stops Andrey from creating his own svn/hg/git/etc repo _just_ for his sade bits. It's easy. This is what I would do even just for my own sake. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On 08.04.2010 14:15, Alexander Leidinger wrote: We don't grant non-committers access to the Subversion repo. Ooops... seems I misremembered his status. Somehow I associate him with something FreeBSD related. Andrey, did you participate in a GSoC? No, I'm not fit for GSoC. My suggestion is to add a "sysinstall mode" to sade where it operates under certain (minor) constraints and reports what it did in a format that sysinstall can parse, so sysinstall can just fork-exec sade instead of duplicating the code. I like this idea. Any way i'll try to finish my work myself. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Rui Paulo writes: > Dag-Erling Smørgrav writes: > > Alexander Leidinger writes: > > > Please consider using SVN instead. A lot more users will be able > > > to check out from there. > > We don't grant non-committers access to the Subversion repo. > The SVN repo is available to the public via HTTP. AFAIK, the OP is not a committer, and hence does not have write access. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Alexander Leidinger writes: > I think this is more complicated than to refactor the interesting part > into a backend with an API which both tools can use. This would also > allow someone to write a GUI program (e.g. for PC-BSD). There have been at least three or four attempts to do this in the past. One of them was even fully funded by the FreeBSD Foundation. They all failed. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
gpart and sector size
Hello.
There is only one possibility to change sector size of physical disk (gnop -S
4096 ...).
May be it is possible to add such possibility to gpart? e.g. gpart create -S
4096 -t gpt ad0?
It will help all unlucky WD Advanced Format disks users. :-D
--
Alexey Tarasov
(\__/)
(='.'=)
E[: | | | | :]З
(")_(")
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
Alexey Tarasov writes: > There is only one possibility to change sector size of physical disk > (gnop -S 4096 ...). May be it is possible to add such possibility to > gpart? e.g. gpart create -S 4096 -t gpt ad0? I don't quite see how that would work - do you mean gpart should configure a gnop? AFAIK there is no "gnop label", so you can't set up a persistent gnop; you have to set it up manually at boot time every time, and there's a risk that the fs (or other layers higher up) will taste the underlying device instead of the gnop. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
No, no.
I mean that gpart should act like gnop presenting another sector size to user.
I that possible at all?
On 08.04.2010, at 17:36, Dag-Erling Smørgrav wrote:
> I don't quite see how that would work - do you mean gpart should
> configure a gnop? AFAIK there is no "gnop label", so you can't set up a
> persistent gnop; you have to set it up manually at boot time every time,
> and there's a risk that the fs (or other layers higher up) will taste
> the underlying device instead of the gnop.
--
Alexey Tarasov
(\__/)
(='.'=)
E[: | | | | :]З
(")_(")
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Quoting Dag-Erling Smørgrav (from Thu, 08 Apr 2010 14:01:33 +0200): Alexander Leidinger writes: I think this is more complicated than to refactor the interesting part into a backend with an API which both tools can use. This would also allow someone to write a GUI program (e.g. for PC-BSD). There have been at least three or four attempts to do this in the past. One of them was even fully funded by the FreeBSD Foundation. They all failed. I was told a lot of people tried to make the WITH_CTF part working without the need to use -DWITH_CTF each time at the command line and failed. Nevertless I did it. So telling something is not possible because other people tried and failed is ridiculous. If there is no proof that it can not be done, I'm sure someone exists who is able to do it. I stand by my words and still say that it is less complicated to put the logic into a backend-lib. If Andrey has problems to do this, I'm willing to invest some time to mentor him in this regard. BTW: I do not think you talk about a partition editor, but about the complete sysinstall. This is a different beast than only the part which I outlined above. Andrey has already some working stuff which just needs to be refactored into frontend/backend-lib parts. Bye, Alexander. -- UNIX is many things to many people, but it's never been everything to anybody. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On Thursday 08 April 2010 5:05:34 am Dag-Erling Smørgrav wrote: > Alexander Leidinger writes: > > Please consider using SVN instead. A lot more users will be able to > > check out from there. > > We don't grant non-committers access to the Subversion repo. > > > It looks like other people had a look at sysinstall, not at sade. As > > sysinstall is supposed to be used at installation time, and the intent > > for sade was to offer the functionality (or more) of the part of > > sysinstall which is useful after installation (and to prevent admins > > from using sysinstall after the installation to prevent some unwanted > > foot-shooting), I do not think that we need to think about a strong > > lock between sysinstall and sade. > > Yes we do. Otherwise we'll just end up back where we are today, where > if you want anything more complicated than a single-disk install you > have to drop into the fixit shell and do it manually before running the > installation procedure. Anythig that sade can do, we want sysinstall to > do as well, and we don't want to implement everything twice. > > My suggestion is to add a "sysinstall mode" to sade where it operates > under certain (minor) constraints and reports what it did in a format > that sysinstall can parse, so sysinstall can just fork-exec sade instead > of duplicating the code. Actually, I would rather have sysinstall just invoke sade to do the disk related stuff. Also, I think sysinstall should allow for a "back-door" mode where a user can setup partitions however they like and mount them at /mnt and then let sysinstall use the setup the user created. This will allow users to setup more complex setups that sysinstall/sade do not currently support and allow sade to focus on simpler, common usage cases w/o having to handle painful edge cases. It would also allow for new modules to be added to sade over time w/o requiring it to support every possible disk layout from the beginning. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On 8 Apr 2010, at 13:49, John Baldwin wrote: > On Thursday 08 April 2010 5:05:34 am Dag-Erling Smørgrav wrote: >> Alexander Leidinger writes: >>> Please consider using SVN instead. A lot more users will be able to >>> check out from there. >> >> We don't grant non-committers access to the Subversion repo. >> >>> It looks like other people had a look at sysinstall, not at sade. As >>> sysinstall is supposed to be used at installation time, and the intent >>> for sade was to offer the functionality (or more) of the part of >>> sysinstall which is useful after installation (and to prevent admins >>> from using sysinstall after the installation to prevent some unwanted >>> foot-shooting), I do not think that we need to think about a strong >>> lock between sysinstall and sade. >> >> Yes we do. Otherwise we'll just end up back where we are today, where >> if you want anything more complicated than a single-disk install you >> have to drop into the fixit shell and do it manually before running the >> installation procedure. Anythig that sade can do, we want sysinstall to >> do as well, and we don't want to implement everything twice. >> >> My suggestion is to add a "sysinstall mode" to sade where it operates >> under certain (minor) constraints and reports what it did in a format >> that sysinstall can parse, so sysinstall can just fork-exec sade instead >> of duplicating the code. > > Actually, I would rather have sysinstall just invoke sade to do the disk > related stuff. Also, I think sysinstall should allow for a "back-door" mode > where a user can setup partitions however they like and mount them at /mnt > and > then let sysinstall use the setup the user created. This will allow users to > setup more complex setups that sysinstall/sade do not currently support and > allow sade to focus on simpler, common usage cases w/o having to handle > painful edge cases. It would also allow for new modules to be added to sade > over time w/o requiring it to support every possible disk layout from the > beginning. I couldn't agree more. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
Alexey Tarasov writes: > I mean that gpart should act like gnop presenting another sector size > to user. I that possible at all? That depends on the underlying partition scheme. My guess is "no". (it all boils down to whether the desired logical sector size can somehow be recorded on-disk) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
Ok, in case of GPT? :-)
GPT implementation can be the simplest solution to this problem compared to
implementing additional ATA commands to determine if disk is in Advanced Format.
On 08.04.2010, at 18:09, Dag-Erling Smørgrav wrote:
> Alexey Tarasov writes:
>> I mean that gpart should act like gnop presenting another sector size
>> to user. I that possible at all?
>
> That depends on the underlying partition scheme. My guess is "no".
>
> (it all boils down to whether the desired logical sector size can
> somehow be recorded on-disk)
>
--
Alexey Tarasov
(\__/)
(='.'=)
E[: | | | | :]З
(")_(")
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Alexander Leidinger writes: > Dag-Erling Smørgrav writes: > > There have been at least three or four attempts to do this in the > > past. One of them was even fully funded by the FreeBSD Foundation. > > They all failed. > I was told a lot of people tried to make the WITH_CTF part working > without the need to use -DWITH_CTF each time at the command line and > failed. Nevertless I did it. So telling something is not possible > because other people tried and failed is ridiculous. It's not ridiculous, it's experience. *Painful* experience over a period of nearly 15 years. > BTW: I do not think you talk about a partition editor, but about the > complete sysinstall. Yes and no. I'm talking about making the user interface pluggable, i.e. run the same program (whether sysinstall or sade) with, say, an ncurses interface on the console and a gtk interface in X. Debian's package system does this, to a certain extent, but only for very simple configuration questions - about the same level of functionality that you get with an HTML form. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
John Baldwin writes:
> Dag-Erling Smørgrav writes:
> > My suggestion is to add a "sysinstall mode" to sade where it
> > operates under certain (minor) constraints and reports what it did
> > in a format that sysinstall can parse, so sysinstall can just
> > fork-exec sade instead of duplicating the code.
> Actually, I would rather have sysinstall just invoke sade to do the
> disk related stuff.
...which is exactly what I said - but in the sysinstall case, you may
want to ask some additional questions ("are you sure you want to proceed
without a swap partition?") or place some additional constraints (such
as "don't allow the user to mount something on top of /mnt or /rescue"),
and sysinstall needs to know the outcome.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
Alexey Tarasov writes: > Ok, in case of GPT? :-) I doubt it, but I don't know for sure. > GPT implementation can be the simplest solution to this problem > compared to implementing additional ATA commands to determine if disk > is in Advanced Format. There are two issues: 1) There is already an ATA command to report both physical and logical sector sizes, but the disk lies - it always reports 512/512. 2) The disk may have already been formatted on a system that doesn't support 4k sectors, and may contain unaligned partitions and file systems, which won't be visible if we forcibly and unconditionally use 4k sectors. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
> 1) There is already an ATA command to report both physical and logical
> sector sizes, but the disk lies - it always reports 512/512.
Advanced Format disks reports 512, but there is another command in ATA standard
which can tell us if it uses 4k sector.
> 2) The disk may have already been formatted on a system that doesn't
> support 4k sectors, and may contain unaligned partitions and file
> systems, which won't be visible if we forcibly and unconditionally
> use 4k sectors.
I mean that when I create *NEW* GPT scheme I can set up sector size emulation.
It will never touch existing unaligned partitions.
--
Alexey Tarasov
(\__/)
(='.'=)
E[: | | | | :]З
(")_(")
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
Alexey Tarasov writes: > Advanced Format disks reports 512, but there is another command in ATA > standard which can tell us if it uses 4k sector. Send me one and I'll look into it :) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Quoting Dag-Erling Smørgrav (from Thu, 08 Apr 2010 16:15:27 +0200): Alexander Leidinger writes: Dag-Erling Smørgrav writes: > There have been at least three or four attempts to do this in the > past. One of them was even fully funded by the FreeBSD Foundation. > They all failed. I was told a lot of people tried to make the WITH_CTF part working without the need to use -DWITH_CTF each time at the command line and failed. Nevertless I did it. So telling something is not possible because other people tried and failed is ridiculous. It's not ridiculous, it's experience. *Painful* experience over a period of nearly 15 years. BTW: I do not think you talk about a partition editor, but about the complete sysinstall. Yes and no. I'm talking about making the user interface pluggable, i.e. run the same program (whether sysinstall or sade) with, say, an ncurses interface on the console and a gtk interface in X. I did not suggest to run the same program and get different interfaces. My suggestion was to have a backend-lib and a frontend. The backend containing the "business-logic", and the frontend being the presentation layer. If you want a GTK GUI, write a new frontend. In the case of sysinstall and sade, both use some kind of curses interface, my suggestion was to the lib as they are both 2 different kind of frontends (two different kinds of point of view regarding the required functionality). I was misunderstanding your idea in the beginning, I was understanding the description of jhb better. It surely is an applicable idea (and an improvement to what we have currently), but it looks like it is limiting what we could do with sade (the frontend part, not the backend part) if it would be decoupled from sysinstall. Bye, Alexander. -- BOFH excuse #144: Too few computrons available http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf
> References
> The ATA8-ACS and SBC-3 standards have provisions for a disk drive to report
> Advanced Format sector sizes and other performance optimization information.
> These standards are used for SATA, SAS, USB, and IEEE 1394 based interface
> technologies.
On 08.04.2010, at 18:35, Dag-Erling Smørgrav wrote:
> Alexey Tarasov writes:
>> Advanced Format disks reports 512, but there is another command in ATA
>> standard which can tell us if it uses 4k sector.
>
> Send me one and I'll look into it :)
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
--
Alexey Tarasov
(\__/)
(='.'=)
E[: | | | | :]З
(")_(")
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Hi, PseudoCylon wrote: > Hi, > > Sorry for taking long to fix. Here is another patch. > > **But before trying it out, please check rev. of your system.** > > If you are using r206358 (15:29 UTC Apr. 7) or newer, the driver won't work. > If you are using older system, please try this patch. > http://projects.nasreddine.com/projects/run/repository/revisions/mips1_fix/show/dev/usb/wlan > Only if_run.c is patched since last time. (click file name, then click > "download") > > Ok, here it is: http://freebsd.pastebin.com/g2YBBDeG > If you are using r206358 or newer, please give me some time to fix. I'm > stating it now. > > Is your kernel compiled with INVARIANTS option? > Tried, but if_arge panics at boot with INVARIANTS option. arge0: at mem 0x1900-0x19000fff irq 2 on nexus0 panic: mtx_lock() of spin mutex arge mii lock @ /usr/mysrc/sys/mips/atheros/if_arge.c:554 thanks, Ganbold Ts > AK > > > > - Original Message > >> From: Ganbold >> To: PseudoCylon >> Cc: freebsd-current@freebsd.org >> Sent: Tue, April 6, 2010 7:29:16 AM >> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >> >> PseudoCylon wrote: >> - Original Message >> >> >> >>> From: Ganbold < >>> >> href="mailto:ganb...@gmail.com";>ganb...@gmail.com> >> >>> To: >>> >> PseudoCylon < >> href="mailto:moonlightak...@yahoo.ca";>moonlightak...@yahoo.ca> >> >> Cc: >> href="mailto:freebsd-current@freebsd.org";>freebsd-current@freebsd.org >> >> Sent: Wed, March 31, 2010 8:08:29 AM >> >>> Subject: Re: CALL for TEST >>> >> [HOSTAP] run(4) ralink usb wireless >> >>> Does stock run(4) >>> >> support hostap mode yet? >> >>> >>> >> No. There >> were some bugs and I thought I fixed them. So, I called for test. It seems >> the >> driver is working on x86, but not on mips. hostap mode should work on your >> other >> computer with i386. >> >> I'm still working on patch. It panics where >> there wasn't any changes made. Strange... >> >> >> > > Hi, > > Sorry, it looks like I missed some of your emails. > Please > >> let me know if you need any info from my >> side. >> > > thanks, > > Ganbold > > >> AK >> >> >> > > > __ > Looking for the perfect gift? Give the gift of Flickr! > > http://www.flickr.com/gift/ > > -- MONTANA: Where forty-three below keeps out the riff-raff. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Alexander Leidinger writes: > I did not suggest to run the same program and get different > interfaces. My suggestion was to have a backend-lib and a frontend. > The backend containing the "business-logic", and the frontend being > the presentation layer. What you call the presentation layer is actually 80% of the work. What you call the business logic already exists (libgeom). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS DEADLKRES
2010/2/22 Marcin Cieslak : > > > > On Sat, 20 Feb 2010, Attilio Rao wrote: > >> 2010/2/18 Marcin Cieslak : >>> >>> My r203753 amd64 laptop falls into the deadlock situation >>> every night while running periodic daily script. I am pretty >>> certain this is related to ZFS. >>> >>> I have enabled DEADLKRES in the kernel. I even have >>> a separate dump partition (not used for swap). >> >> May you reproduce the bug with WITNESS? >> If you can, you should enable DEADLKRES too and once it panics let >> extract a textdump(4) with the following commands: >> bt, ps, show alllocks, show pcpu, allthreads > > Unfortunately, there is no way to write anything to disk. > All attempts to talk to the ata subsystem from ddb(4) > fail with EIO (probably timeout). This may be a false positive. May you please try the following patch and report if you can fix it does fix it or not?: http://www.freebsd.org/~attilio/Sandvine/deadlkres/deadlkres-blessed.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On 04/08/2010 14:39, Alexander Leidinger wrote: Quoting Dag-Erling Smørgrav (from Thu, 08 Apr 2010 16:15:27 +0200): Alexander Leidinger writes: Dag-Erling Smørgrav writes: > There have been at least three or four attempts to do this in the > past. One of them was even fully funded by the FreeBSD Foundation. > They all failed. I was told a lot of people tried to make the WITH_CTF part working without the need to use -DWITH_CTF each time at the command line and failed. Nevertless I did it. So telling something is not possible because other people tried and failed is ridiculous. It's not ridiculous, it's experience. *Painful* experience over a period of nearly 15 years. BTW: I do not think you talk about a partition editor, but about the complete sysinstall. Yes and no. I'm talking about making the user interface pluggable, i.e. run the same program (whether sysinstall or sade) with, say, an ncurses interface on the console and a gtk interface in X. I did not suggest to run the same program and get different interfaces. My suggestion was to have a backend-lib and a frontend. The backend containing the "business-logic", and the frontend being the presentation layer. If you want a GTK GUI, write a new frontend. In the case of sysinstall and sade, both use some kind of curses interface, my suggestion was to the lib as they are both 2 different kind of frontends (two different kinds of point of view regarding the required functionality). I was misunderstanding your idea in the beginning, I was understanding the description of jhb better. It surely is an applicable idea (and an improvement to what we have currently), but it looks like it is limiting what we could do with sade (the frontend part, not the backend part) if it would be decoupled from sysinstall. Bye, Alexander. That's a pretty similar to the approach we've taken with our new backend in PC-BSD 8.x. The notable exception is that instead of just a lib, our backend is a complete program (written in sh), which performs scripted installs, and provides all the functionality for front-ends to query the system and present data to the end-user. This has a few advantages, in that the backend can be used stand-alone for scripted installations and also provide great flexibility to the front-end developer. They don't need to worry about performing any of the actual installation logic, they just provide a way for users to select their installation options, generate a configuration script, and let the backend run with it. -- Kris Moore PC-BSD Software iXsystems ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
On Thu, 8 Apr 2010 18:40:50 +0400 Alexey Tarasov wrote: > http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf > > > References > > The ATA8-ACS and SBC-3 standards have provisions for a disk drive to report > > Advanced Format sector sizes and other performance optimization > > information. These standards are used for SATA, SAS, USB, and IEEE 1394 > > based interface technologies. > This is apparently the Long Physical Sector features set. The question is whether it's been implemented. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
On 2010-04-08 17:24, Gary Jennejohn wrote: References The ATA8-ACS and SBC-3 standards have provisions for a disk drive to report Advanced Format sector sizes and other performance optimization information. These standards are used for SATA, SAS, USB, and IEEE 1394 based interface technologies. This is apparently the Long Physical Sector features set. The question is whether it's been implemented. Isn't this already done? At least it looks like it: http://svn.freebsd.org/viewvc/base?view=revision&revision=198897 It might even have been MFC'd... :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When will we can use ZFS v24?
> ZFS is still currently in heavy development so it might happen. Having siad > that it looks like oracle have totally buggered it up for everyone with > their retroactive licenses. I hope the CDL was tight enough that stuff wont > have to get pulled from freebsd is that even possible with CDDL? Sam Fourman Jr. Fourman Networks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On Thu, 08 Apr 2010 10:53:48 +, Kris Moore wrote: It's not nice to hijack a topic, but this is way to interesting for me, so I do it anway :) > This has a few advantages, in that the backend can be used stand-alone > for scripted installations and also provide great flexibility > to the front-end developer. They don't need to worry about performing > any of the actual installation logic, they just provide a way > for users to select their installation options, generate a configuration > script, and let the backend run with it. scripted installation! Are you able to do a pxeboot, nfsroot and then scripted installation? Are those scripts portable to FreeBSD or PC-BSD only? Could you give me a hint where to find them? TIA, Marian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On 04/08/2010 16:30, Marian Hettwer wrote: On Thu, 08 Apr 2010 10:53:48 +, Kris Moore wrote: It's not nice to hijack a topic, but this is way to interesting for me, so I do it anway :) :) I didn't mean to hijack either, was trying to discuss advantage of having backend as a executable vs a library which can't be used standalone without front-end. This would in effect lock you completely into front-end logic, which may not meet a users specific needs, even though backend can do what user wants. This has a few advantages, in that the backend can be used stand-alone for scripted installations and also provide great flexibility to the front-end developer. They don't need to worry about performing any of the actual installation logic, they just provide a way for users to select their installation options, generate a configuration script, and let the backend run with it. scripted installation! Are you able to do a pxeboot, nfsroot and then scripted installation? Are those scripts portable to FreeBSD or PC-BSD only? Could you give me a hint where to find them? TIA, Marian Correct, every install it does is a fully-scripted installation, and it can be used with pxeboot, or in a custom mfsroot image easily. Supports ZFS, glabel, gmirror, geli, GPT, gpart, vanilla FreeBSD installs, etc. http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall Checkout examples/README for all the gory details of config-file generation. One caveat, the version in trunk is being very actively worked on by myself at the moment to prepare for 8.1, needs more docs, etc ;) -- Kris Moore PC-BSD Software iXsystems ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
I too love the idea of "generalizing" (abstracting) the dirty-work to a
set of libraries and leaving the user interface up to the userland
applications. Thusly, an app in /usr/X11R6/bin can use said libraries in
plugging in functionality to an X11 GUI application, meanwhile an app
in /bin or /sbin (presumably, since we're talking about low-level system
utilities) could use the same libraries for plugging the same
functionality into a command-line interface (beit command-driven or
ncurses/libdialog driven).
However, I'm still wondering what that change would mean to our beloved
sysinstall when it comes time to place sysinstall into the mfsroot for
the CD-ROM installer.
Currently, the mfsroot contains very little in the ways of ELF binaries:
-sh, [ (test), arp, boot_crunch, camcontrol, cpio, dhclient, find,
fsck_4.2bsd, fsck_ffs, fsck_ufs, gunzip, gzip, hostname, ifconfig,
minigzip, mount_nfs, newfs, ppp, pwd, rm, route, rtsol, sed, sh,
sysinstall, test, tunefs, usbconfig, and zcat
Every last one of those is (a) statically linked and (b) hard-linked to
one-another (really, they are all hard-links to boot_crunch which is a
by-product of crunchgen(1)).
What might the landscape look like if we move down the road toward
separating the back-end from the front-end?
Presumably though, we could simply put the bits back together, no?
Currently, the following libraries are slurped into the crunchgen
configuration:
-ll, -ledit, -lutil, -lmd, -lcrypt, -lftpio, -lz, -lnetgraph, -ldialog,
-lncurses, -ldisk, -lcam, -lsbuf, -lufs, -ldevinfo, -lbsdxml, -larchive,
-lbz2, -lusb, and -ljail
Which I show to be these files in RELENG_8:
/usr/lib/libl.a
/usr/lib/libedit.a
/usr/lib/libutil.a
/usr/lib/libmd.a
/usr/lib/libcrypt.a
/usr/lib/libftpio.a
/usr/lib/libz.a
/usr/lib/libnetgraph.a
/usr/lib/libdialog.a
/usr/lib/libncurses.a
/usr/lib/libdisk.a
/usr/lib/libcam.a
/usr/lib/libsbuf.a
/usr/lib/libufs.a
/usr/lib/libdevinfo.a
/usr/lib/libbsdxml.a
/usr/lib/libarchive.a
/usr/lib/libbz2.a
/usr/lib/libusb.a
/usr/lib/libjail.a
I think I just answered my own question...
We should have no problem re-incorporating any heretofore developed
libraries (for the back-end functionality) *back into* the crunchgen
(1)'ed binaries.
In fact, if we, say for example, developed /usr/lib/libsysinstall.a
and /usr/lib/libsade.a , we could then simply just patch
`/usr/src/release/i386/boot_crunch.conf' in the following manner:
[dte...@push800 /usr/src/release/i386]$ diff -u boot_crunch.conf{.bak,}
--- boot_crunch.conf.bak2010-04-08 07:10:49.0 -0700
+++ boot_crunch.conf2010-04-08 07:10:27.0 -0700
@@ -46,3 +46,4 @@
libs -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph
libs -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo
libs -lbsdxml -larchive -lbz2 -lusb -ljail
+libs -lsysinstall -lsade
Assuming of course that `release' (and intrinsically `buildworld') is
made to generate the libraries
at /R/stage/trees/base/usr/lib/libsysinstall.a
and /R/stage/trees/base/usr/lib/libsade.a (and respectively for
`buildworld', /usr/obj/usr/src/tmp/usr/lib/libsysinstall.a
and /usr/obj/usr/src/tmp/usr/lib/libsade.a).
So, I guess my fears of "mucking up" the install environment are
unfounded.
All-in-all, I'm right there with y'all on the idea of separating the
front-end from the back-end. It needs to be done (and will open up a
flurry of new installer interfaces and utilities that require low-end
stuff usually own made-available by sysinstall internals).
--
Devin
On Thu, 2010-04-08 at 16:19 +0200, Dag-Erling Smørgrav wrote:
> John Baldwin writes:
> > Dag-Erling Smørgrav writes:
> > > My suggestion is to add a "sysinstall mode" to sade where it
> > > operates under certain (minor) constraints and reports what it did
> > > in a format that sysinstall can parse, so sysinstall can just
> > > fork-exec sade instead of duplicating the code.
> > Actually, I would rather have sysinstall just invoke sade to do the
> > disk related stuff.
>
> ...which is exactly what I said - but in the sysinstall case, you may
> want to ask some additional questions ("are you sure you want to proceed
> without a swap partition?") or place some additional constraints (such
> as "don't allow the user to mount something on top of /mnt or /rescue"),
> and sysinstall needs to know the outcome.
>
> DES
--
Cheers,
Devin Teske
-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.te...@fisglobal.com
-> LEGAL DISCLAIMER <-
This message contains confidential and proprietary information
of the sender, and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person is strictly prohibited. If you have received this
message in error, please notify the e-mail sender immediately,
and delete the original message without making a copy.
-> END TRANSMISSION <-
Re: [RFC] Rewriting sade(8)
(( wishing that I hadn't un-CC'd the group on earlier e-mails )) Some concerns that I have with separating the code into a back-end versus front-end... 1. Is it currently the idea that -- when it comes down to the crunchgen stuff -- we are going to re-work the code that generates the non-shared binaries for mfsroot? or move away from the crunchgen/mfsroot paradigm? 2. If moving away from crunchgen/mfsroot, ... are we effectively making the statement that we no longer "support" installing FreeBSD on your floppy-enabled kitchen toaster? I'm not saying that there's an overwhelming need to retain the ability to install FreeBSD via floppy, ... but it uber-legacy support is something to be proud-of (just as lack-thereof could perhaps be something to be ashamed of -- I can fall into either camp channeling visions of Steve-Jobs-style mac-like shunning of the floppy drive or even Bill Gates almost sickening legacy- support of DOS). 3. We could abandon chrunchgen/mfsroot and simply load up all the back- end bits with the front-end bits for sysinstall to function in the installer environment ... but my quarrel is ... will it still fit on a floppy? if not, are we prepared to deprecate that? otherwise, does anyone care that the installer environment will be changing from a collection of staticallly-linked binaries to a "mess" ? I actually have a really nifty idea for deprecating mfsroot... and that's to start using syslinux as the boot-loader (which as of version 3.84 supports booting *.iso files). We're doing that in our company now... we have a CD-ROM that boots SYSLINUX and displays a menu with many options (among them "FreeBSD"). Selecting "FreeBSD" from the menu uses SYSLINUX's "memdisk" module to then boot `mdroot.iso' which essentially an `mfsroot'. The benefit here is that the `mdroot.iso' can be built cross-platform (matters not if you download our CVS tree to a Linux box or FreeBSD box... as long as you have `mkisofs' you can "compile" the disc and all incumbent file systems). The further beauty of this method is that the resultant mdroot.iso can be large (currently 14MB in our company ... but that's only because it contains two monolithic custom kernels which -- because we have a custom boot loader that allows us to cycle through any number of kernels at boot time to select the proper one for the hardware in question). -- Devin On Thu, 2010-04-08 at 15:08 +0100, Rui Paulo wrote: > On 8 Apr 2010, at 13:49, John Baldwin wrote: > > > On Thursday 08 April 2010 5:05:34 am Dag-Erling Smørgrav wrote: > >> Alexander Leidinger writes: > >>> Please consider using SVN instead. A lot more users will be able to > >>> check out from there. > >> > >> We don't grant non-committers access to the Subversion repo. > >> > >>> It looks like other people had a look at sysinstall, not at sade. As > >>> sysinstall is supposed to be used at installation time, and the intent > >>> for sade was to offer the functionality (or more) of the part of > >>> sysinstall which is useful after installation (and to prevent admins > >>> from using sysinstall after the installation to prevent some unwanted > >>> foot-shooting), I do not think that we need to think about a strong > >>> lock between sysinstall and sade. > >> > >> Yes we do. Otherwise we'll just end up back where we are today, where > >> if you want anything more complicated than a single-disk install you > >> have to drop into the fixit shell and do it manually before running the > >> installation procedure. Anythig that sade can do, we want sysinstall to > >> do as well, and we don't want to implement everything twice. > >> > >> My suggestion is to add a "sysinstall mode" to sade where it operates > >> under certain (minor) constraints and reports what it did in a format > >> that sysinstall can parse, so sysinstall can just fork-exec sade instead > >> of duplicating the code. > > > > Actually, I would rather have sysinstall just invoke sade to do the disk > > related stuff. Also, I think sysinstall should allow for a "back-door" > > mode > > where a user can setup partitions however they like and mount them at /mnt > > and > > then let sysinstall use the setup the user created. This will allow users > > to > > setup more complex setups that sysinstall/sade do not currently support and > > allow sade to focus on simpler, common usage cases w/o having to handle > > painful edge cases. It would also allow for new modules to be added to > > sade > > over time w/o requiring it to support every possible disk layout from the > > beginning. > > I couldn't agree more. > > Regards, > -- > Rui Paulo > -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s)
Re: [RFC] Rewriting sade(8)
Randi and I were discussion the possibility of having sysinstall "remember" what you did and then able to write out a suitable `install.cfg' file that could be subsequently used to perform a human- less automated install with the same settings. To expand a little on that... I'd like to draw a similarity to AppleScript. If you are familiar with AppleScript, you know that one can launch on Macintoshes (going back as far as Mac OS 7.0.1) an application known as the "Script Editor" which had a "Record" button in the [then] top-left corner of the window. After clicking that "Record" button, the system then recorded what you did (including in the Desktop [Finder] and other 3rd-party programs) and saved a series of scripted commands which could simply be "Run" (or optionally saved into an executable script) to reproduce everything you did at-once. The way that this worked was by way of the developer "plugging in" specific resources (if you're familiar with the ol' days, you'll undoubtedly remember ResEdit -- specifically, a developer would add an 'aete' resource to the RSRC fork of the HFS file structure (among others). Then, when a scriptable-action was performed within the application, rather than calling some internally obscure sub-routine to perform the task, the developer would have the application actually send an AppleScript event to the MacOS which then sent it back to the application. Therefore, when the ScriptEditor is "recording", what it records is the events being passed from the application to itself as you go about clicking, dragging and typing things. It is in this manner that I think we would be best served in contemplating a "self-scripting" engine. That is to say, that -- altogether now -- we: a. separate the GUI front-end from the actual tasks that need to be performed (back-end; for example, tasks to partition disks, perform newfs, etc. etc.) b. have either all commands in the library pass through a "dispatcher" or only export a single dispatcher function from the library (requiring all "commands" to pass through this single function) Then it would then (I perceive) perhaps become a trivial task to have the dispatcher "record" the events. Another benefit of this would be that it wouldn't matter whom or what performed anything at all... there would be a mechanism for recording what was done regardless. And thus, we would usher in the age of being even the lay user being able to script the installer to do his/her bidding. No? -- Devin On Thu, 2010-04-08 at 12:48 +, Kris Moore wrote: > On 04/08/2010 16:30, Marian Hettwer wrote: > > On Thu, 08 Apr 2010 10:53:48 +, Kris Moore wrote: > > > > It's not nice to hijack a topic, but this is way to interesting for me, so > > I do it anway :) > > > :) I didn't mean to hijack either, was trying to discuss advantage of > having backend > as a executable vs a library which can't be used standalone without > front-end. > This would in effect lock you completely into front-end logic, which may > not meet > a users specific needs, even though backend can do what user wants. > > >> This has a few advantages, in that the backend can be used stand-alone > >> for scripted installations and also provide great flexibility > >> to the front-end developer. They don't need to worry about performing > >> any of the actual installation logic, they just provide a way > >> for users to select their installation options, generate a configuration > >> > > > >> script, and let the backend run with it. > >> > > scripted installation! > > Are you able to do a pxeboot, nfsroot and then scripted installation? > > Are those scripts portable to FreeBSD or PC-BSD only? > > Could you give me a hint where to find them? > > > > TIA, > > Marian > > > > Correct, every install it does is a fully-scripted installation, and > it can be used with pxeboot, or in a custom mfsroot image easily. > Supports ZFS, glabel, gmirror, geli, GPT, gpart, vanilla FreeBSD > installs, etc. > > http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall > > Checkout examples/README for all the gory details of config-file > generation. > > One caveat, the version in trunk is being very actively worked on by > myself at the > moment to prepare for 8.1, needs more docs, etc ;) > -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- __
Re: [RFC] Rewriting sade(8)
2010/4/8 Dag-Erling Smørgrav :
> John Baldwin writes:
>> Dag-Erling Smørgrav writes:
>> > My suggestion is to add a "sysinstall mode" to sade where it
>> > operates under certain (minor) constraints and reports what it did
>> > in a format that sysinstall can parse, so sysinstall can just
>> > fork-exec sade instead of duplicating the code.
>> Actually, I would rather have sysinstall just invoke sade to do the
>> disk related stuff.
>
> ...which is exactly what I said - but in the sysinstall case, you may
> want to ask some additional questions ("are you sure you want to proceed
> without a swap partition?") or place some additional constraints (such
> as "don't allow the user to mount something on top of /mnt or /rescue"),
> and sysinstall needs to know the outcome.
If the user shoots him or herself in the foot, that's their own
problem. They should at least read hier(7) or ask a question on
questions@ beforehand. As long as the auto-partitioner is correct,
it's fine. Complicating the tool with a lot of unnecessary criteria
will just produce unnecessary bloat.
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
Garrett Cooper writes: > If the user shoots him or herself in the foot, that's their own > problem. That kind of attitude is why people choose Linux over FreeBSD... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On Thu, Apr 8, 2010 at 10:01 AM, Devin Teske wrote: > Randi and I were discussion the possibility of having sysinstall > "remember" what you did and then able to write out a suitable > `install.cfg' file that could be subsequently used to perform a human- > less automated install with the same settings. [...] > On Thu, 2010-04-08 at 12:48 +, Kris Moore wrote: >> On 04/08/2010 16:30, Marian Hettwer wrote: >> > On Thu, 08 Apr 2010 10:53:48 +, Kris Moore wrote: >> > >> > It's not nice to hijack a topic, but this is way to interesting for me, so >> > I do it anway :) >> > >> :) I didn't mean to hijack either, was trying to discuss advantage of >> having backend >> as a executable vs a library which can't be used standalone without >> front-end. >> This would in effect lock you completely into front-end logic, which may >> not meet >> a users specific needs, even though backend can do what user wants. >> >> >> This has a few advantages, in that the backend can be used stand-alone >> >> for scripted installations and also provide great flexibility >> >> to the front-end developer. They don't need to worry about performing >> >> any of the actual installation logic, they just provide a way >> >> for users to select their installation options, generate a configuration >> >> >> > >> >> script, and let the backend run with it. >> >> >> > scripted installation! >> > Are you able to do a pxeboot, nfsroot and then scripted installation? >> > Are those scripts portable to FreeBSD or PC-BSD only? >> > Could you give me a hint where to find them? >> > >> > TIA, >> > Marian >> > >> >> Correct, every install it does is a fully-scripted installation, and >> it can be used with pxeboot, or in a custom mfsroot image easily. >> Supports ZFS, glabel, gmirror, geli, GPT, gpart, vanilla FreeBSD >> installs, etc. >> >> http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall >> >> Checkout examples/README for all the gory details of config-file >> generation. >> >> One caveat, the version in trunk is being very actively worked on by >> myself at the >> moment to prepare for 8.1, needs more docs, etc ;) 1. Please don't top post :). 2. install.cfg is just a hacky / non-style(9) compliant way of specifying how to do an install. If you could separate out sysinstall into separate utilities and have each of the pieces execute as shell commands with predefined variables at install, you'll be lightyears ahead of where sysinstall is today. 3. sysinstall(8) does a lot of crud that it shouldn't do for all systems. Powerusers won't use sysinstall because does too much crap; all of the items that sysinstall does behind the scenes to get a working system should be properly documented in a doc article. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
On Apr 8, 2010, at 6:06 AM, Alexey Tarasov wrote: > Hello. > > There is only one possibility to change sector size of physical disk (gnop -S > 4096 ...). > May be it is possible to add such possibility to gpart? e.g. gpart create -S > 4096 -t gpt ad0? > It will help all unlucky WD Advanced Format disks users. :-D A better approach is to have tunables for geom_disk to do this. This should absolutely not be part of a partitioning tool. It violates everything there is to violate AFAICT. FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
2010/4/8 Dag-Erling Smørgrav : > Garrett Cooper writes: >> If the user shoots him or herself in the foot, that's their own >> problem. > > That kind of attitude is why people choose Linux over FreeBSD... Where do you draw the line though? /media, /libexec, /proc, /sys, etc? I think it's better to educate users than build in more complexity to the install application. Besides, how many people have you heard of that created slices for /mnt or /rescue lately? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
Hello.
Thank you for the information.
In 8-STABLE snapshot 201002 diskinfo shows 512k sector size yet.
I will try CURRENT tomorrow.
On 08.04.2010, at 19:35, Dimitry Andric wrote:
> On 2010-04-08 17:24, Gary Jennejohn wrote:
References
The ATA8-ACS and SBC-3 standards have provisions for a disk drive to
report Advanced Format sector sizes and other performance optimization
information. These standards are used for SATA, SAS, USB, and IEEE 1394
based interface technologies.
>>>
>>
>> This is apparently the Long Physical Sector features set. The question is
>> whether it's been implemented.
>
> Isn't this already done? At least it looks like it:
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=198897
>
> It might even have been MFC'd... :)
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
--
Alexey Tarasov
(\__/)
(='.'=)
E[: | | | | :]З
(")_(")
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
2010/4/8 Garrett Cooper : > 2010/4/8 Dag-Erling Smørgrav : >> Garrett Cooper writes: >>> If the user shoots him or herself in the foot, that's their own >>> problem. >> >> That kind of attitude is why people choose Linux over FreeBSD... > > Where do you draw the line though? /media, /libexec, /proc, /sys, > etc? I think it's better to educate users than build in more > complexity to the install application. > Besides, how many people have you heard of that created slices for > /mnt or /rescue lately? Sorry -- meant partition -_-... Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On 04/08/2010 18:15, Garrett Cooper wrote: On Thu, Apr 8, 2010 at 10:01 AM, Devin Teske wrote: Randi and I were discussion the possibility of having sysinstall "remember" what you did and then able to write out a suitable `install.cfg' file that could be subsequently used to perform a human- less automated install with the same settings. In a sense that's what our back-end / front-end is doing currently. The program flow works like thus: Front-end starts, queries all relevant information from back-end, Disks, Network Cards, etc, then proceeds to walk the user through the steps gathering enough information to perform an installation. This gives front-end control over its own data gathering logic from the user, since the way I do something in a QT GUI may not work via command-line without a mouse or the other way around. When we are done gathering information, the front-end writes out an install.cfg directive and starts the back-end processing it. The front-end then waits and displays backend output to the user in a sane manner, allowing user to watch whats going on. (example) http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall/examples/pcinstall.cfg.zfs So with this method, its pretty much doing what you describe. Every install is a scripted install, and if you want to do unattended installs, you can use the front-end to generate all the options you want, copy and/or tweak the resulting config to be used again later. If the backend is simply a library and not executable, then you'll end up needing scripting support or ways to run one implemented directly in each front-end, which can get messy to maintain across curses/gtk/qt/web, etc. -- Kris Moore PC-BSD Software iXsystems ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
I agree with you completely.
Seems that support of this disks is already commited in CURRENT, will try it
tomorrow.
> A better approach is to have tunables for geom_disk to do this. This should
> absolutely
> not be part of a partitioning tool. It violates everything there is to
> violate AFAICT.
> FYI,
--
Alexey Tarasov
(\__/)
(='.'=)
E[: | | | | :]З
(")_(")
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Rewriting sade(8)
On Thu, Apr 8, 2010 at 11:15 AM, Garrett Cooper wrote:
> 2. install.cfg is just a hacky / non-style(9) compliant way of
> specifying how to do an install. If you could separate out sysinstall
> into separate utilities and have each of the pieces execute as shell
> commands with predefined variables at install, you'll be lightyears
> ahead of where sysinstall is today.
What does style(9) have to do with install.cfg? From the header in the
man page, style(9) is a "kernel source file style guide". install.cfg
is a configuration file. It is not source code. install.cfg isn't as
good as it could be, admittedly. Like much of sysinstall, it needs
some work, but I wouldn't call it "hacky". It's readable and fairly
easy to understand.
What you're talking about doing is rewriting all of sysinstall. How
many people have said at some point "I'm going to rewrite sysinstall"
or "I'm going to write a replacement for sysinstall"? How many of
those people were successful? We're working on a plan and tackling one
problem at a time, keeping goals manageable. As a result, sysinstall
is getting more TLC now than it has in a very long time.
> 3. sysinstall(8) does a lot of crud that it shouldn't do for all
> systems. Powerusers won't use sysinstall because does too much crap;
> all of the items that sysinstall does behind the scenes to get a
> working system should be properly documented in a doc article.
I consider myself a poweruser, and I've stuck to using sysinstall. I
just select 'custom'. I know a lot of other powerusers - people that
have been sysadmins for a very long time - that also use sysinstall.
Please don't presume to speak for sysadmins everywhere.
I'm not sure what "crud" you're talking about in specific. There's
some things I'd like to see go away (some of the post-install
configuration bits, how the ports tree is installed). There will be an
epic discussion soon of where we'd all like to see sysinstall go
("away" is not the answer I'm looking for :D), but this is going off
topic of the original thread.
There's a lot of work being done to sysinstall right now by a number
of people. I don't want to further complicate things by pushing what
you're suggesting into the mix. What we're discussing at the moment is
sade/sysinstall specific and affects what happens in the immediate
future, not a laundry list of "this is why sysinstall sucks". File a
PR. Submit patches.
-- randi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart and sector size
On 2010-04-08 21:34, Alexey Tarasov wrote: Thank you for the information. In 8-STABLE snapshot 201002 diskinfo shows 512k sector size yet. I will try CURRENT tomorrow. It looks like the code was MFC'd to stable/8 in r199443. However, even in -CURRENT, the sector size you see in diskinfo will also be 512B. For ada(4) disks, it seems the d_sectorsize field of geom_disk's struct disk is initialized using the _logical_ sector size, not the physical sector size (which may be a multiple of the logical sector size). That said, if the physical sector size is larger than the logical sector size, the d_stripesize field is initialized with it. So if you run "diskinfo -v" on the disk, what is the output for stripesize? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When will we can use ZFS v24?
On 8 April 2010 17:47, Sam Fourman Jr. wrote: > > ZFS is still currently in heavy development so it might happen. Having > siad > > that it looks like oracle have totally buggered it up for everyone with > > their retroactive licenses. I hope the CDL was tight enough that stuff > wont > > have to get pulled from freebsd > > is that even possible with CDDL? > > Sam Fourman Jr. > Fourman Networks > im not a lawyer but it wouldn't surprise me ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When will we can use ZFS v24?
Hi-- On Apr 8, 2010, at 2:18 PM, krad wrote: [ ... ] >> is that even possible with CDDL? >> > > im not a lawyer but it wouldn't surprise me I'm not a lawyer either, but I was active in reviewing and suggesting changes to CDDL submission for OSI approval back in 2004. A copyright owner always has the ability to relicense their code under other terms, but existing code is guaranteed to be available, redistributable to others, etc under the terms of the current version of CDDL; in particular see: > 4. Versions of the License. > > • 4.1. New Versions. > > Sun Microsystems, Inc. is the initial license steward and may publish revised > and/or new versions of this License from time to time. Each version will be > given a distinguishing version number. Except as provided in Section 4.3, no > one other than the license steward has the right to modify this License. > > • 4.2. Effect of New Versions. > > You may always continue to use, distribute or otherwise make the Covered > Software available under the terms of the version of the License under which > You originally received the Covered Software. If the Initial Developer > includes a notice in the Original Software prohibiting it from being > distributed or otherwise made available under any subsequent version of the > License, You must distribute and make the Covered Software available under > the terms of the version of the License under which You originally received > the Covered Software. Otherwise, You may also choose to use, distribute or > otherwise make the Covered Software available under the terms of any > subsequent version of the License published by the license steward. If Oracle chooses, they might make future changes to the ZFS source code under different or more restrictive licensing terms, but what's available now is always going to be available. Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r206358/r206369 prevent me from connecting via wpi0
Rui, I updated my kernel to the latest today, and was unable to connect via wireless. I have a 3945ABG using wpi. I rolled back to r206357 and everything worked fine. I then rolled forward to r206369 (your rate control mod + bug fixes and - debugging code) and it stopped working. I didn't bother picking up r206370-2 since I don't have the affected devices and had already tried a more recent kernel. I'm on a C2D using i386 and SMP in case it matters. I use wpa2 on my access point. Let me know if there is any other information that you need. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_enable
On 04/04/10 22:49, Hiroki Sato wrote: > Doug Barton wrote > in <4bb95564.1070...@freebsd.org>: > > do> On 04/04/10 02:41, Hiroki Sato wrote: > do> > "Kevin Oberman" wrote > do> > in <20100404053352.e6f751c...@ptavv.es.net>: > do> > > do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts > and I > do> > ob> see no reason not to use them to enable or disable functionality > whether > do> > ob> it involves a script in rc.d or not. The idea is to have a clear, > do> > ob> obvious way to enable or disable functionality. I see nothing in > Hiroki's > do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. > do> > > do> > Another reason I lean to not using xxx_enable is that an rc.d knob > do> > cannot control enabling/disabling the IPv6 functionality actually. > do> > It was true even when we were using the network_ipv6 script. > do> > do> But that's equally true of how you're using ipv6_prefer. :) You've > do> basically just moved the overloading of 2 of the 3 previous functions of > do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 > do> functions into different knobs. > > No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. if checkyesno ipv6_prefer; then _ipv6_opts="-ifdisabled" else _ipv6_opts="ifdisabled" fi In any case, I give up. Reasonable arguments for not continuing to pursue ipv6_enable: 1. Of those who expressed an opinion, it was roughly evenly divided between support and opposition. 2. In the months since your original commit, I'm the only one who has expressed a strong preference for keeping it. Unreasonable arguments: I am completely out of time and energy to continue discussing it. So, I just committed r206408 that has most of my previously posted changes, but altered to fit both the lack of ipv6_enable, and the requirement to explicitly configure the interface. I've chosen to take the complete lack of commentary on any of my previous patches to be implicit approval of the changes. The one area where we did seem to reach consensus is that ipv6_network_interfaces=AUTO is a reasonable intermediate step, so I've included that change as well. The actual changes and the rationale for them are described in the commit message. The documentation in rc.conf.5 is greatly expanded as well, which I think should make things perfectly clear. With these changes you can now configure RA as simply as adding ifconfig__ipv6=RTADV to rc.conf (assuming of course that INET6 is in the kernel). The lo0 interface will continue to be configured by default. If there are no ifconfig__ipv6 options for any of the other interfaces they will not be configured for IPv6 at all. Any commentary on the technical merits of the changes is welcome assuming that the code has been reviewed and understood. Regards, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_enable
[ snipped ] On 04/05/10 08:52, Bjoern A. Zeeb wrote: > > I have no idea (unless I'll read them) about the guts of various shell > function magic we use to configure interfaces, and I heck do not care > about where it's called autoblah_foo or zigbangbusheek as none of our > users does, so I'll ignore that. I'll probably have to comment on a > few rc.conf knobs as that's all a user cares about. Agreed. I've tried to make the point repeatedly that the users should not have to learn about the internals to do simple enabling of the interface. > Neither IPv4 nor IPX have an _enable="" knob in defaults/rc.conf > and I cannot see why we would need it for IPv6. You don't configure > it on an interface you don't have it configured an interface. > The fact that it had been there for IPv6 is historic and could have > been a good or bad idea at that time during the early days of > development. I am actully too lazy to see why it had really been added. See my answer to Hiroki. Since there was no clear consensus to keep ipv6_enable I agree to allow it to stay deprecated. > I wouldn't want to have a link-local address on my non-loopback > interfaces working unless I asked for them. That's why we had > ipv6_autolinklocal in the past and that's why the current rc/devd/iface > framework prevents this from happening unless explicitly asked for. > That's why there is nd6 options=. I agree that this is a feature, and I've maintained it in the changes I just committed. > I am trying to think of a reason I had needed ipv6_interfaces in the > past and I can find some. I have checked my current configurations > and I couldn't find any instance of *interfaces anymore. Being able > to use ifconfig_**, especially with the IPv6 per interface options, > seems to have fixed all for me with the current implementation. It's probably worth pointing out that this is because of the defaults in /etc/defaults/rc.conf. > Why do we need ipv6_prefer? Well, actually we do not need it. We > could have people use ip6addrctl and a static config file with their > preference. Here I disagree. Having a nice knob in rc.conf makes this an easy thing for users to configure, and is consistent with your point of view above that users should not have to learn about the internals to do simple configuration. > So what do you people actually want to change? You want auto-magic to > happen (again) that suits your local setup or that does what we used > to have in the 5.x days? Well put your "local" needs into > ifconfig__ipv6 and be done. For the record, I resent your implication that my motivations are personal. I wasn't even using the stock interface until recently, and I am more than capable of writing all the custom configuration scripts I need. My motivation is simply to keep things simple for our users, and avoid what I consider to be a POLA violation. However, given the lack of consensus around keeping the ipv6_enable option I'll accept the community's decision and move on. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: When will we can use ZFS v24?
On Thu, Apr 8, 2010 at 2:30 PM, Chuck Swiger wrote: > Hi-- > > On Apr 8, 2010, at 2:18 PM, krad wrote: > [ ... ] >>> is that even possible with CDDL? >>> >> >> im not a lawyer but it wouldn't surprise me > > I'm not a lawyer either, but I was active in reviewing and suggesting changes > to CDDL submission for OSI approval back in 2004. > > A copyright owner always has the ability to relicense their code under other > terms, but existing code is guaranteed to be available, redistributable to > others, etc under the terms of the current version of CDDL; in particular see: > >> 4. Versions of the License. >> >> • 4.1. New Versions. >> >> Sun Microsystems, Inc. is the initial license steward and may publish >> revised and/or new versions of this License from time to time. Each version >> will be given a distinguishing version number. Except as provided in Section >> 4.3, no one other than the license steward has the right to modify this >> License. >> >> • 4.2. Effect of New Versions. >> >> You may always continue to use, distribute or otherwise make the Covered >> Software available under the terms of the version of the License under which >> You originally received the Covered Software. If the Initial Developer >> includes a notice in the Original Software prohibiting it from being >> distributed or otherwise made available under any subsequent version of the >> License, You must distribute and make the Covered Software available under >> the terms of the version of the License under which You originally received >> the Covered Software. Otherwise, You may also choose to use, distribute or >> otherwise make the Covered Software available under the terms of any >> subsequent version of the License published by the license steward. > > If Oracle chooses, they might make future changes to the ZFS source code > under different or more restrictive licensing terms, but what's available now > is always going to be available. The same of basic principle applies to BDB; originally it was BSD licensed in 1.x under FreeBSD, then GPLed in 2.x+ (IIRC), then left to pasture in 4.x after Oracle acquired Sleepycat DB. MySQL is GPLv2 today... who knows what it might be tomorrow... Cheers, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
load ipfw table addresses from file
hi! is there any plans to implement such opportunities? for large files (we have 60k lines) it's very slow work srv1# sh -E # wc -l /root/scripts/db/table.25.txt 61073 /root/scripts/db/table.25.txt # date && for i in `cat /root/scripts/db/table.25.txt`; do ipfw table 25 add $i; done && date пятница, 9 апреля 2010 г. 10:42:01 (MSD) пятница, 9 апреля 2010 г. 10:52:43 (MSD) # it took more than 10 minutes on busy server =( ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
