Re: [RFC] Rewriting sade(8)
09.04.10, 11:20, Garrett Cooper yanef...@gmail.com: Ok. Or maybe since `we're here' sade needs to be populating $DESTDIR/etc/fstab, not sysinstall ? I'm also looking for answer to this question. It seems that all basic operations with partitions are already implemented. And I think about next steps. Also I think I should make a dialog for writing bootcode. And there are a bunch of different bootstrap code which can be used with different schemes. So if anyone can share own experience I'll be grateful. MBR: /boot/mbr - standart boot record (is it needed? Is it not the same which gpart creates?). /boot/boot0 - boot0 boot manager. /boot/boot0sio - boot0 boot manager with redirected output ot com1. correct me if I'm wrong, is MBR the only one that can be used to change the boot partition via menu? and also via serial? BTW, you said you would look into boot0cfg :-) GPT: /boot/pmbr - protective mbr /boot/gptboot - bootstrap code for booting from GPT, should be installed to freebsd-boot partition. /boot/gptzfsboot - bootstrap code for booting from GPT and ZFS, should be installed to freebsd-boot partition. /boot/zfsboot - bootstrap code for booting from ZFS from MBR, it seems this bootcode doesn't have a correct way (e.g `gpart bootcode ...`) to be writed. What about VTOC8, PC98, APM? -- 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 ___ 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 14.04.2010 13:28, Daniel Braniss wrote: correct me if I'm wrong, is MBR the only one that can be used to change the boot partition via menu? and also via serial? BTW, you said you would look into boot0cfg :-) At this thime I implemented writing bootstrap code only for MBR and GPT schemes. For MBR scheme user can select one from Standart MBR and Boot Manager. For GPT scheme user can select ZFS-aware gptzfsboot and gptboot. Currently I'm working on File Systems Editor. But here are lot of work. -- 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)
Garrett Cooper yanef...@gmail.com writes: Now you're making a dangerous assumption that /inst isn't being used by the end-user for any predefined purpose. No, I'm making the entirely reasonable assumption that *during the installation process* sysinstall can mount whatever the hell it wants wherever the hell it wants. Why is this so hard to understand? If the user wants to create an /inst filesystem *during installation* it will be mounted as /inst/inst. If the user runs sade *at a later time* and creates an /inst filesystem, it will be mounted as /inst. Ok. Or maybe since `we're here' sade needs to be populating $DESTDIR/etc/fstab, not sysinstall ? At that time (when sysinstall invokes sade) there is no $DESTDIR/etc - sysinstall hasn't yet started extracting the base distribution. 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 d...@des.no (from Thu, 08 Apr 2010 16:50:16 +0200): Alexander Leidinger alexan...@leidinger.net 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). That's an oversimplification. There is more code which can be shared. Bye, Alexander. -- I'm RELIGIOUS!! I love a man with a HAIRPIECE!! Equip me with MISSILES!! 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)
Garrett Cooper yanef...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: Garrett Cooper yanef...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: [restored relevant context which was removed earlier in the thread] ...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. 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. I draw the line at mounting something - anything - on top of directories that contain files that are critical to sysinstall's operation. IIRC, /mnt is where the installation CD is mounted. In sysinstall mode, sade's role is to 1) make sure that something sensible is mounted in the location where sysinstall is going to install the OS, 2) assist the user in making the correct disk, slice, partition or what-have-you bootable, 3) within reasonable limits, prevent the user from doing something that will break sysinstall, and 4) optionally allow the user to prepare additional filesystems that sysinstall doesn't care about (e.g. /usr/obj), as long as this does not conflict with 3). I think the easiest way to achieve this is for sysinstall to provide an empty directory (e.g. /inst) and have sade operate with that directory as root, so what the user sees is how things will look when the system reboots after installation; when the user asks sade to create /usr/obj, sade actually creates /inst/usr/obj. Last but not least, sade should report what it did to sysinstall - perhaps in fstab format, since sysinstall needs to populate (/inst)/etc/fstab anyway. 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)
Dag-Erling Smørgrav wrote: Garrett Cooper yanef...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: Garrett Cooper yanef...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: [restored relevant context which was removed earlier in the thread] ...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. 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. I draw the line at mounting something - anything - on top of directories that contain files that are critical to sysinstall's operation. IIRC, /mnt is where the installation CD is mounted. In sysinstall mode, sade's role is to 1) make sure that something sensible is mounted in the location where sysinstall is going to install the OS, 2) assist the user in making the correct disk, slice, partition or what-have-you bootable, 3) within reasonable limits, prevent the user from doing something that will break sysinstall, and 4) optionally allow the user to prepare additional filesystems that sysinstall doesn't care about (e.g. /usr/obj), as long as this does not conflict with 3). I think the easiest way to achieve this is for sysinstall to provide an empty directory (e.g. /inst) and have sade operate with that directory as root, so what the user sees is how things will look when the system reboots after installation; when the user asks sade to create /usr/obj, sade actually creates /inst/usr/obj. Last but not least, sade should report what it did to sysinstall - perhaps in fstab format, since sysinstall needs to populate (/inst)/etc/fstab anyway. DES But... If this is a fresh install, then you really have not lost anything if you making a mistake. If sysinstall / sade is run from a running system and a mistake is made then you could loose your data, but as you will need to have su-ed up, how does this differ from typing a wrong command in? Just my 2 cents Paul ___ 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)
Paul Wootton p...@fletchermoorland.co.uk writes: But... If this is a fresh install, then you really have not lost anything if you making a mistake. If sysinstall / sade is run from a running system and a mistake is made then you could loose your data, but as you will need to have su-ed up, how does this differ from typing a wrong command in? Please, please, go have a cup of coffee, then come back and *read what I wrote* instead of just making stuff up. 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 Friday 09 April 2010 5:23:18 am Dag-Erling Smørgrav wrote: Garrett Cooper yanef...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: Garrett Cooper yanef...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: [restored relevant context which was removed earlier in the thread] ...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. 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. I draw the line at mounting something - anything - on top of directories that contain files that are critical to sysinstall's operation. IIRC, /mnt is where the installation CD is mounted. FYI, the CD is mounted at /dist. sysinstall mounts the new filesystems in /mnt and then chroots into /mnt before doing the actual install. -- 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)
2010/4/9 Dag-Erling Smørgrav d...@des.no: Garrett Cooper yanef...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: Garrett Cooper yanef...@gmail.com writes: Dag-Erling Smørgrav d...@des.no writes: [restored relevant context which was removed earlier in the thread] ...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. 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. I draw the line at mounting something - anything - on top of directories that contain files that are critical to sysinstall's operation. IIRC, /mnt is where the installation CD is mounted. Ok... rather than hardcoding this list into sysinstall or sade, it would be nice if it was in some kind of flexible metadata. In sysinstall mode, sade's role is to 1) make sure that something sensible is mounted in the location where sysinstall is going to install the OS, 2) assist the user in making the correct disk, slice, partition or what-have-you bootable, What is sensible today, may not be sensible for all cases or sensible tomorrow. For instance, there have been some reports about the `Auto defaults' in sysinstall completely screwing up the size as the default was way too low for /, and thus a user shot himself in the foot when doing a binary upgrade via freebsd-update. This `smart default' needs to exist as a minimum and maximum defined in some kind of metadata, and it would definitely help if one knew what the use-case would be for the machine, but one doesn't know this data from the way that things have been setup. 3) within reasonable limits, prevent the user from doing something that will break sysinstall, Point being, how do you qualify the act of not `break[ing] sysinstall'? and 4) optionally allow the user to prepare additional filesystems that sysinstall doesn't care about (e.g. /usr/obj), as long as this does not conflict with 3). I think the easiest way to achieve this is for sysinstall to provide an empty directory (e.g. /inst) and have sade operate with that directory as root, so what the user sees is how things will look when the system reboots after installation; when the user asks sade to create /usr/obj, sade actually creates /inst/usr/obj. Now you're making a dangerous assumption that /inst isn't being used by the end-user for any predefined purpose. Last but not least, sade should report what it did to sysinstall - perhaps in fstab format, since sysinstall needs to populate (/inst)/etc/fstab anyway. Ok. Or maybe since `we're here' sade needs to be populating $DESTDIR/etc/fstab, not sysinstall ? Ideally sysinstall should be a thin wrapper over a number of different utilities which would provide the code for thinking things together, not doing a bunch of operations. That way the code itself could be divorced from the activities it's performing a bit better and people could swap in other solutions as they feel fit (say the PCBSD QT installer, or the myriad of different installers available today for FreeBSD in GTK, QT, etc format). 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: Re: [RFC] Rewriting sade(8)
09.04.10, 11:20, Garrett Cooper yanef...@gmail.com: Ok. Or maybe since `we're here' sade needs to be populating $DESTDIR/etc/fstab, not sysinstall ? I'm also looking for answer to this question. It seems that all basic operations with partitions are already implemented. And I think about next steps. Also I think I should make a dialog for writing bootcode. And there are a bunch of different bootstrap code which can be used with different schemes. So if anyone can share own experience I'll be grateful. MBR: /boot/mbr - standart boot record (is it needed? Is it not the same which gpart creates?). /boot/boot0 - boot0 boot manager. /boot/boot0sio - boot0 boot manager with redirected output ot com1. GPT: /boot/pmbr - protective mbr /boot/gptboot - bootstrap code for booting from GPT, should be installed to freebsd-boot partition. /boot/gptzfsboot - bootstrap code for booting from GPT and ZFS, should be installed to freebsd-boot partition. /boot/zfsboot - bootstrap code for booting from ZFS from MBR, it seems this bootcode doesn't have a correct way (e.g `gpart bootcode ...`) to be writed. What about VTOC8, PC98, APM? -- 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)
On Thursday 08 April 2010 06:25:47 Andrey V. Elsukov wrote: 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. 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. -- Bruce Cran ___ 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 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. 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 :) -- 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)
2010/4/7 Andrey V. Elsukov bu7c...@yandex.ru: 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: [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 bu7c...@yandex.ru (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: [RFC] Rewriting sade(8)
Alexander Leidinger alexan...@leidinger.net 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 alexan...@leidinger.net 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 d...@des.no (from Thu, 08 Apr 2010 11:05:34 +0200): Alexander Leidinger alexan...@leidinger.net 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 alexan...@leidinger.net 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 alexan...@leidinger.net 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 rpa...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Alexander Leidinger alexan...@leidinger.net 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 alexan...@leidinger.net 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
Re: [RFC] Rewriting sade(8)
Quoting Dag-Erling Smørgrav d...@des.no (from Thu, 08 Apr 2010 14:01:33 +0200): Alexander Leidinger alexan...@leidinger.net 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 alexan...@leidinger.net 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 alexan...@leidinger.net 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: [RFC] Rewriting sade(8)
Alexander Leidinger alexan...@leidinger.net writes: Dag-Erling Smørgrav d...@des.no 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 j...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no 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: [RFC] Rewriting sade(8)
Quoting Dag-Erling Smørgrav d...@des.no (from Thu, 08 Apr 2010 16:15:27 +0200): Alexander Leidinger alexan...@leidinger.net writes: Dag-Erling Smørgrav d...@des.no 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: [RFC] Rewriting sade(8)
Alexander Leidinger alexan...@leidinger.net 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: [RFC] Rewriting sade(8)
On 04/08/2010 14:39, Alexander Leidinger wrote: Quoting Dag-Erling Smørgrav d...@des.no (from Thu, 08 Apr 2010 16:15:27 +0200): Alexander Leidinger alexan...@leidinger.net writes: Dag-Erling Smørgrav d...@des.no 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: [RFC] Rewriting sade(8)
On Thu, 08 Apr 2010 10:53:48 +, Kris Moore k...@pcbsd.org 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 Moorek...@pcbsd.org 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 j...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no 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 alexan...@leidinger.net 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) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited.
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 Moorek...@pcbsd.org 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 - ___ freebsd-current@freebsd.org mailing list
Re: [RFC] Rewriting sade(8)
2010/4/8 Dag-Erling Smørgrav d...@des.no: John Baldwin j...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no 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 yanef...@gmail.com 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 dte...@vicor.com 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 Moorek...@pcbsd.org 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: [RFC] Rewriting sade(8)
2010/4/8 Dag-Erling Smørgrav d...@des.no: Garrett Cooper yanef...@gmail.com 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: [RFC] Rewriting sade(8)
2010/4/8 Garrett Cooper yanef...@gmail.com: 2010/4/8 Dag-Erling Smørgrav d...@des.no: Garrett Cooper yanef...@gmail.com 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 Teskedte...@vicor.com 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: [RFC] Rewriting sade(8)
On Thu, Apr 8, 2010 at 11:15 AM, Garrett Cooper yanef...@gmail.com 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: [RFC] Rewriting sade(8)
On Wed, Apr 7, 2010 at 9:35 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
Hi, All.
Some days ago i begun rewriting sade(8) to libgeom(3). Just for fun :-)
Today i have progress and you can see some screenshoots here:
http://butcher.heavennet.ru/sade/
What is done:
1. It's fully rewritten, but yes, i reuse some code from old sade.
2. I wrote small framework customdlg for creating custom dialogs (not yet
fully finished, but works).
3. Now sade use libgeom for searching providers and it can use:
{DISK, disk device},
{MD, memory backed virtual disk},
{ZFS::ZVOL, ZFS volume},
{MIRROR, GEOM based mirror (RAID1)},
{STRIPE, GEOM based stripe (RAID0)},
{RAID3, GEOM based RAID3 array},
{CONCAT, GEOM based concatenated disk},
{ELI, GEOM based encrypted disk},
{JOURNAL, GEOM based journalled disk},
{MULTIPATH, GEOM based disk with multiple path}
4. Access to partitions based on geom_part.so library. I made some changes in
geom_part.c and
sent it to Marcel, but currently didn't receive answer. Any way if these
changes is not acceptable
i can rewrite it for using libgeom(3) only.
5. Undo/Commit features are based on internal implementation of geom class
PART. I found there
two bugs:
http://lists.freebsd.org/pipermail/freebsd-geom/2010-April/004018.html
http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039390.html
6. All device related code can be placed in shared library and in future
can be reused in another
frontend...
7. New Partition Editor:
* partitions list now scrollable;
* all operations based on geom_part.so and similar to gpart(8);
* opening partition editor on empty provider opens new Selech Partitioning
Scheme dialog
and create selected scheme;
* new add slice dialog;
* deleting slice from empty table destroys scheme;
Todo:
1. Refine customdlg.
2. Waiting for fixes in geom_part_mbr, geom_part and geom_part.so.
3. Set Type and Label dialog.
4. Better wording needed for messages and help. My english is bad :(
--
Missing functions:
Creating filesystem and save them into /etc/fstab.
What new can be added:
1. Creating ZFS pools and datasets.
2. Creating GEOM-based raids.
Any comments are welcome.
--
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
Wow. This is awesome. patches? :D
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. :)
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.
CC:ing Devin Teske on this thread, as he's displayed interest in
helping as well. My goal is to get all this in for 8.2, so there's
quite a bit to work out in a short period of time.
-- 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: [RFC] Rewriting sade(8)
On Wed, Apr 07, 2010 at 10:49:35AM -0700, Randi Harper wrote:
On Wed, Apr 7, 2010 at 9:35 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
Hi, All.
Some days ago i begun rewriting sade(8) to libgeom(3). Just for fun :-)
Today i have progress and you can see some screenshoots here:
http://butcher.heavennet.ru/sade/
What is done:
1. It's fully rewritten, but yes, i reuse some code from old sade.
2. I wrote small framework customdlg for creating custom dialogs (not yet
fully finished, but works).
3. Now sade use libgeom for searching providers and it can use:
{DISK, disk device},
{MD, memory backed virtual disk},
{ZFS::ZVOL, ZFS volume},
{MIRROR, GEOM based mirror (RAID1)},
{STRIPE, GEOM based stripe (RAID0)},
{RAID3, GEOM based RAID3 array},
{CONCAT, GEOM based concatenated disk},
{ELI, GEOM based encrypted disk},
{JOURNAL, GEOM based journalled disk},
{MULTIPATH, GEOM based disk with multiple path}
4. Access to partitions based on geom_part.so library. I made some changes
in geom_part.c and
sent it to Marcel, but currently didn't receive answer. Any way if these
changes is not acceptable
i can rewrite it for using libgeom(3) only.
5. Undo/Commit features are based on internal implementation of geom class
PART. I found there
two bugs:
http://lists.freebsd.org/pipermail/freebsd-geom/2010-April/004018.html
http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039390.html
6. All device related code can be placed in shared library and in future
can be reused in another
frontend...
7. New Partition Editor:
* partitions list now scrollable;
* all operations based on geom_part.so and similar to gpart(8);
* opening partition editor on empty provider opens new Selech Partitioning
Scheme dialog
and create selected scheme;
* new add slice dialog;
* deleting slice from empty table destroys scheme;
Todo:
1. Refine customdlg.
2. Waiting for fixes in geom_part_mbr, geom_part and geom_part.so.
3. Set Type and Label dialog.
4. Better wording needed for messages and help. My english is bad :(
--
Missing functions:
Creating filesystem and save them into /etc/fstab.
What new can be added:
1. Creating ZFS pools and datasets.
2. Creating GEOM-based raids.
Any comments are welcome.
--
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
Wow. This is awesome. patches? :D
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. :)
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.
I have half-finished code that uses /sbin/gpart instead of libdisk or libgeom.
Half-finished, because it initialy used /sbin/{fidsk,bsdlabel,gpt}
So now I plan to finish the conversion to gpart and add work with gpt to
mbr and bsdlable handling.
CC:ing Devin Teske on this thread, as he's displayed interest in
helping as well. My goal is to get all this in for 8.2, so there's
quite a bit to work out in a short period of time.
-- randi
--
Adios
___
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 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 ___ 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
