Re: Installation on Macbook Pro
Christopher Rawnsley wrote: Here is a little update for my problem... On 12 Mar 2008, at 02:48, YONETANI Tomokazu wrote: IIRC, you need to fiddle with ad5*. A better alternative I can think of is to partition (or maybe even disklabel it and newfs -O1) using FreeBSD installer first, then boot with DragonFly LiveCD, and continue the rest of procedure explained in /README . Formatting with FreeBSD worked fine. FreeBSD appeared to have formatted the disk differently by switching the slice order. So the 165 ID (DragonFly/Free BSD) slice came before my 175 ID (HFS+) slice even though the physical disk layout was the other way round (Significant at all?). I now had a properly sliced drive so I rebooted with DF which could now write to the disk :). Thank you for that, Yonetani. So I rebooted and this time booted from the hard drive. Boot loader came up! Unfortunately, it couldn't boot the DF slice. So I went back to the CD and (this is where I got a bit stupid...) fired up fdisk to check everything out. Nothing to odd. Had a look at gpt's output too. Which I found to be a little odd. The DF slice shared the same index (of 1) with my EFI slice with Mac OS X at index 2. Let me first explain that, from what I read, in order for a computer to comply with EFI they have to have an extra slice set aside for EFI. On my laptop that means that I have this in the form of a 200MB slice with the rest for whatever. > > Now I remember seeing when Mac OS X and Windows was installed, I booted into the DF live CD and ran gpt. The output that time around was EFI slice at 1, Mac OS X at 2 and Windows at 3. Even though I don't think boot0 can boot from the GPT, I wonder whether the FreeBSD installer changed something in a similar way to the MBR. Very speculative, I know but I can't check out anymore 'cause... Side Note: Recall my saying Apple marched to the beat of a different orchestra? If memory serves, this is where some of that shows. There isn't just one such 'hidden' slice - there is one preceding *every other* slice/partition. I.E. my 6 UFS slices, having been set up with OS X have 6 100 MB slices in between them. There is information about this online in OS X-specific articles, and it is why I suggest using a separate HDD entirely, as I do with *BSD/PPc (FW800 is *fast*, and even USB 2.) is decent) Going on my hunch that something in the MBR was wrong and was causing boot0 to not read it properly I decided to open up fdisk and see if I could find anything that might be a cause. I checked each slice through using the -u option (IIRC) and when I got the the Mac OS X slice it complained about the head boundaries being all wrong. I rather stupidly thought that I'd let it automatically update this. This caused nothing to boot etc. Long story short I ended wiping everything in favour of it being quicker for me (I had deadlines to meet...). It was all backed up so hopefully that won't keep anyone awake at night! Just for 'education' as to how different things really are - creadm, but do not alter, with both fdisk and disklabel from FreeBSD/PPc AND OpenBSD PPc as well as DFLY. I think I will come back to DF in the not so distant future but I'm just going to let myself go on other things for now. Thanks a lot to all you guys who tried to help me. I really appreciate it :) -- Chris P.S. Would it be possible to by pass the MBR all together in favour of GPT by simply using another boot loader other than boot0 Yes - though that isn't entirely 'bypassing' the MBR in all cases, it can be made so. See the various 'boot floppy' methods, including grub (compex for complexity's own sake, but flexible) and 'GAG' (simple, but effective) or even Warp LVM if you can get your hands on a copy - then think USB stick instead of floppy. It is also fairly easy to alter and re-assemble boot0 to build a custom loader. Even if asm language is not your long suit, the code is in 'symbolic' assembler, and there is very littel of it, so is easy to grok. (Mine drops never-used-here FAT/NTFS/DOS recognition in favor of grokking Minix, Solaris, Syllable, fs types for example) or would this also require changes in the kernel or elsewhere? Not required - yet. Potential gains *could* be had where multiple controllers and drives exist - my 'normal' environment. What is wanted is that the next two stages are as BFBI simple as boot0. Ex: If changing drive order (cartridges, externals) or controller channel-order, the visible part is an fstab that 'follows suit'. In FreeBSD or DFLY, this can be accomplished by creative disklabeling and such, e.g. : - set up a RAID1 array with (n)atacontrol, even if you never add the second drive. fstab will have entries such as /dev/ar(x)s(n) - which will be 'found' even if the devices of the set that had been /dev/ad0 moves to /dev/ad6 or ad10. Similar with GEOM / GMIRROR in FreeBSD. - in FreeBSD (haven't tested with DFLY), use /dev/u
SoC2008 student guidelines
http://wiki.dragonflybsd.org/index.cgi/GoogleSoC2008Student Please comment on it or just add to it (since it's on the wiki). Any changes/additions in the next day or so will be used for the student application template I'm providing to Google, so if you've got something to add - you know what to do.
DFly and SOC2008
Hi! I am a computer science student from Sweden that is doing my last year now (hopefully). I am studying to become a civil engineer in information technology. I am a bit interested in this years Google SOC and was looking at the "Extend Multi-Processing support" project suggestion. I have never done any kernel programming before and would like to know a bit more about how to go about a project such as this. Performance profiling would also be new to me so more info about it would be appreciated. -- Mvh - Stefan -
Re: [GSoC] the AMD64 port
On Tue, Mar 18, 2008 at 10:36:32PM +0200, Jordan Gordeev wrote: > 1. Does porting require messing with the source code of gcc/binutils/gdb? Not much, if at all. > 2. Do I need to have an AMD64 machine with more than 4 GB RAM to be able > to fully test my work? No. > 3. Would I be required to get 32-bit binaries working on 64-bit kernels or > would being able to run 64-bit binaries suffice? The latter. > 4. Is SMP part of the equation? SMP is almost a non-issue. The only code that is not shared with i386 in this area is the assembly bootstrap for the second CPU, the rest is identical. Joerg
Re: [GSoC] the AMD64 port
Matthew Dillon wrote: :I'm a student interested in doing the AMD64 port as a Google Summer of :Code project. :I would like to have some questions answered, in order to be able to :make an informed decision. : 1. Does porting require messing with the source code of gcc/binutils/gdb? This might need a little work. 64 bit world builds will generate a 64 bit cross compiler which the 64 bit kernel build should use (when building on a 32 bit platform), but currently our libraries in /usr/lib use a single path for 32 or 64 bit libs so we can't build a compiler that supports both. This means you should be able to work on a 64 bit kernel without messing with the compiler sources, though we might need to do a few small cleanups. I think it would be beneficial for our 2.0 release to actually go through the pain of moving our 32 bit libraries into a i386 or amd64 subdirectory, with the original directory turned into a softlink, or something like that so we would be able to have both targets on the same architecture. That's probably a mini-project in of itself. I may be repeating myself :), but I feel I should mention that Noah Yan (the guy who did the pc64/amd64 stuff we have already in base) has ~330KB of uncommitted stuff lying in his git repo at http://repo.or.cz/w/dragonfly/port-amd64.git. It would be a pity if this work would be repeated again. I've put the patch also here: http://leaf.dragonflybsd.org/~swildner/64_yanyh.diff I was thinking about just committing it so others can pick up, although pc64 world is again broken with this stuff in and I also am not 100% sure if it generally makes things better or worse. Have fun, Sascha -- http://yoyodyne.ath.cx
Re: [GSoC] the AMD64 port
I'll add my response to Simon's, we basically say the same thing :-) :I'm a student interested in doing the AMD64 port as a Google Summer of :Code project. :I would like to have some questions answered, in order to be able to :make an informed decision. : 1. Does porting require messing with the source code of gcc/binutils/gdb? This might need a little work. 64 bit world builds will generate a 64 bit cross compiler which the 64 bit kernel build should use (when building on a 32 bit platform), but currently our libraries in /usr/lib use a single path for 32 or 64 bit libs so we can't build a compiler that supports both. This means you should be able to work on a 64 bit kernel without messing with the compiler sources, though we might need to do a few small cleanups. I think it would be beneficial for our 2.0 release to actually go through the pain of moving our 32 bit libraries into a i386 or amd64 subdirectory, with the original directory turned into a softlink, or something like that so we would be able to have both targets on the same architecture. That's probably a mini-project in of itself. : 2. Do I need to have an AMD64 machine with more than 4 GB RAM to be :able to fully test my work? No, any 64 bit capable machine will do. : 3. Would I be required to get 32-bit binaries working on 64-bit :kernels or would being able to run 64-bit binaries suffice? No, 64 bit binaries will suffice. 32 bit support is desired, it makes things easier, but not required. : 4. Is SMP part of the equation? Yes, but UP could be done first. SMP mechanics for 64 bit platforms are virtually identical as those for 32 bit platforms. : 5. In general, is there a fixed list of things that should be done, or :am I free to choose based on my interests/abilitity? You are definitely free to choose. Really, just getting past basic booting would be major milestone! -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: [GSoC] the AMD64 port
Jordan Gordeev wrote: 1. Does porting require messing with the source code of gcc/binutils/gdb? maybe. the basic infrastructure is in place however and also seems to be able to produce amd64 binaries of some sort. 2. Do I need to have an AMD64 machine with more than 4 GB RAM to be able to fully test my work? I don't think so. 3. Would I be required to get 32-bit binaries working on 64-bit kernels or would being able to run 64-bit binaries suffice? 32bit binaries would be optional, but of course the design shouldn't obstruct them. 4. Is SMP part of the equation? I'd say yes, but I don't think there is so much work to do. 5. In general, is there a fixed list of things that should be done, or am I free to choose based on my interests/abilitity? "Make it work" definitely is on the list of things to be done. Apart from that you might be able to choose. I think the list of deliverables would have to be pinned down by you and your mentor. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
[GSoC] the AMD64 port
I'm a student interested in doing the AMD64 port as a Google Summer of Code project. I would like to have some questions answered, in order to be able to make an informed decision. 1. Does porting require messing with the source code of gcc/binutils/gdb? 2. Do I need to have an AMD64 machine with more than 4 GB RAM to be able to fully test my work? 3. Would I be required to get 32-bit binaries working on 64-bit kernels or would being able to run 64-bit binaries suffice? 4. Is SMP part of the equation? 5. In general, is there a fixed list of things that should be done, or am I free to choose based on my interests/abilitity?
eINIT
I came across this today: "eINIT is a replacement for /sbin/init -- the programme that is responsible for booting your computer -- that is all about not wasting resources; that's not wasting CPU cycles, but also not wasting RAM either, which should make eINIT very well suited for embedded applications. However, that's not to say eINIT wouldn't work fine (and swiftly) on regular desktops, laptops or servers." -- http://einit.org/node/63 Thought someone might be interested. It's licensed under the 3-clause BSD and could even make a good GSoC project. -- Chris
Re: Installation on Macbook Pro
Here is a little update for my problem... On 12 Mar 2008, at 02:48, YONETANI Tomokazu wrote: IIRC, you need to fiddle with ad5*. A better alternative I can think of is to partition (or maybe even disklabel it and newfs -O1) using FreeBSD installer first, then boot with DragonFly LiveCD, and continue the rest of procedure explained in /README . Formatting with FreeBSD worked fine. FreeBSD appeared to have formatted the disk differently by switching the slice order. So the 165 ID (DragonFly/Free BSD) slice came before my 175 ID (HFS+) slice even though the physical disk layout was the other way round (Significant at all?). I now had a properly sliced drive so I rebooted with DF which could now write to the disk :). Thank you for that, Yonetani. So I rebooted and this time booted from the hard drive. Boot loader came up! Unfortunately, it couldn't boot the DF slice. So I went back to the CD and (this is where I got a bit stupid...) fired up fdisk to check everything out. Nothing to odd. Had a look at gpt's output too. Which I found to be a little odd. The DF slice shared the same index (of 1) with my EFI slice with Mac OS X at index 2. Let me first explain that, from what I read, in order for a computer to comply with EFI they have to have an extra slice set aside for EFI. On my laptop that means that I have this in the form of a 200MB slice with the rest for whatever. Now I remember seeing when Mac OS X and Windows was installed, I booted into the DF live CD and ran gpt. The output that time around was EFI slice at 1, Mac OS X at 2 and Windows at 3. Even though I don't think boot0 can boot from the GPT, I wonder whether the FreeBSD installer changed something in a similar way to the MBR. Very speculative, I know but I can't check out anymore 'cause... Going on my hunch that something in the MBR was wrong and was causing boot0 to not read it properly I decided to open up fdisk and see if I could find anything that might be a cause. I checked each slice through using the -u option (IIRC) and when I got the the Mac OS X slice it complained about the head boundaries being all wrong. I rather stupidly thought that I'd let it automatically update this. This caused nothing to boot etc. Long story short I ended wiping everything in favour of it being quicker for me (I had deadlines to meet...). It was all backed up so hopefully that won't keep anyone awake at night! I think I will come back to DF in the not so distant future but I'm just going to let myself go on other things for now. Thanks a lot to all you guys who tried to help me. I really appreciate it :) -- Chris P.S. Would it be possible to by pass the MBR all together in favour of GPT by simply using another boot loader other than boot0 or would this also require changes in the kernel or elsewhere?
Re: Soc 2008 - we're in!
On Tue, March 18, 2008 4:23 am, Matthias Schmidt wrote: > Just as a side note: It would be nice if the potential students could > write up a short bio and send it to the list and/or to the mentor. Some > lines about (coding, BSD, DragonFly, UNIX) experience and how you want > to complete the project ;) I plan to write up a student application form tonight so that we can keep consistent track of these things - I'll publish it as soon as I have it.
Re: dma!? (was Re: Soc 2008 - we're in!)
Hi, * Jeremy C. Reed wrote: > > Anyways, this looks like something that should be more publicized. Sure, go ahead :) > Or have I missed hearing about it on this list before? There were some discussions on submit@, commits@ and [EMAIL PROTECTED] Thanks for your report about that -t option. I currently delayed working on dma, because I wanted to wait if a SoC student is willing to take over the remaining work :) The virtualuser table would be called genericstable in sendmail slang (or generic in Postfix IIRC). Regards matthias
Re: Soc 2008 - we're in!
* Justin C. Sherrill wrote: > http://code.google.com/soc/2008/dragonfly/about.html > > Yay us! There were a number of people who had spoken up before; now is > your chance - Sd?vtaker, Robert Luciani + Danwei, Jost Tobias > Springenberg, and Vita "CiV" Cizek were the names I had down. > > If you are an interested student, now is the time to check the Ideas page > on the wiki (link below) or come up with a project of your own. Students > will be able to apply to the Summer of Code starting on March 25th though > March 31st, so please use the intervening time to get it together. Just as a side note: It would be nice if the potential students could write up a short bio and send it to the list and/or to the mentor. Some lines about (coding, BSD, DragonFly, UNIX) experience and how you want to complete the project ;) Regards Matthias
Re: [HEADS UP] Start of the freeze for the pkgsrc-2008Q1 branch
AFAIK, databases/db4 still does not compile on dfly (the patch on pkgsrc-users was not commited as far as I can tell), also xine-lib and libmp4v2 (last time I checked, could have been fixed in the mean time, but after a quick view through gmane.os.netbsd.devel.pkgsrc.cvs, I didn't see anything done for this packages). So the new branch will have all the above software and everything that depends on it broken and hopefully the next branch will have this fixed? Alistair Crooks wrote: > Just a quick heads-up that we've started the freeze on new functionality, > and infrastructure changes, in preparation for the pkgsrc-2008Q1 branch. > > We expect that this freeze will take no longer than 2 weeks. > > With best wishes, > Alistair -- Regards, Rumko
