diff options
Diffstat (limited to 'hurd/libstore/part.mdwn')
| -rw-r--r-- | hurd/libstore/part.mdwn | 133 |
1 files changed, 130 insertions, 3 deletions
diff --git a/hurd/libstore/part.mdwn b/hurd/libstore/part.mdwn index 5260d05d..29ef9072 100644 --- a/hurd/libstore/part.mdwn +++ b/hurd/libstore/part.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2012, 2013 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -28,6 +29,132 @@ A similar problem is described in [[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented. -# TODO +# Open Issues -How to use, etc. +## Documentation + +[[!tag open_issue_documentation]] + +## [[open_issues/hurd_build_without_parted]] + +## IRC, freenode, #hurd. 2013-09-21 + + <phcoder> Hello, guys. Is there a way to know where partition starts on + hurd. E.g. given hd0s1 get "2048 sectors" + <youpi> yes, it's the storeinfo RPC + <youpi> let me find you a pointer + <phcoder> in GRUB 2 files for determining device relations are a mess of + #if's. I try to split it into logical files and make common logic + uniform. Current Hurd's logic is completely different and, actually, + wrong. Same logic is used by Mac OS X part ... + <youpi> phcoder: Mmm, I guess you never got the userland-part.patch + upstream + <youpi> ah, yes ,you did + <youpi> I mean the find_hurd_root_device function + <youpi> grub was previously using file_get_storage_info + <phcoder> youpi: find_hurd_root_Device/file_get_storage info is about + translating / -> /dev/hd0s1. Current problem is in step hd0s1 -> + hd0,msdos1 + <youpi> yes, but iirc file_get_storage_info might work for hd0s1 itself + <phcoder> I see, let me try this + <phcoder> youpi: file_get_storage gives offset=0 size=partition size + <youpi> (file_get_storage) damn + <phcoder> and name=hd0s1 + <youpi> ah, that might be because we're still using in-kernel partition + table, instead of the parted partition table + <phcoder> looks like file_get_storage would be useful to get block size + though + <phcoder> youpi: is parted already used in some cases? Any reliable way to + check for it? Any way to access kernel partition map? Ioctl? RPC to + kernel? + <youpi> the parted table is only enabled in the debian installer for + now. You can set up one for yourself by running e.g. settrans -c + /tmp/myhd0s1 /hurd/storeio -T typed part:1:device:hd0 + <youpi> I don't think there is any ioctl/RPC to get the kernel partition + table + <phcoder> youpi: is it using Linux partition code with some glue? + <youpi> phcoder: the kernel partition table, yes + <phcoder> youpi: that's bad. it's probably one of the least consistent + numbering schemes. It would imply that it only worked because only + simplest cases were ever tested + <youpi> I know + <youpi> that's why we want to migrate to the parted-based partition table + support + <youpi> (which also brings us much better support than the old linux2.0 + code :) ) + <phcoder> youpi: I've looked into code and must say that I dislike what I + see: partitions handled in ide/ahci/sd/... + <youpi> phcoder: which code? + <phcoder> youpi: gnumach + <youpi> sure, that's not what we want in the end + <phcoder> grep -r start_sect + <youpi> it's just the legacy linux way of doing partition support + <phcoder> Well Linux at least gives a meaningful ioctl + <phcoder> couldn't find any hint of it in gnumach + <youpi> we didn't bother to add one since the parted way is supposed to be + what we have in the end + <phcoder> youpi: I can't make our code follow sth that might be the case in + the future + <youpi> why not? + <youpi> that's the way we will go + <youpi> it's not just hypothetic + <youpi> we just can't continue maintaining disk drivers in the kernel + <youpi> so it won't be in the kernel + <phcoder> youpi: if I do then GRUB won't work on current GNU/Hurd anymore + <youpi> can't you also keep the old code? + <youpi> as a fallback when the proper way does not work (yet) + <phcoder> More hairs... :( + <phcoder> How do I check for it? offset == 0 isn't proper as partitions may + start at 0 + <phcoder> but checking than name still refers to partition is probably the + right way + <youpi> I don't see what you mean + <youpi> (about name) + <phcoder> youpi: I mean that we need a way to know that current code is + used and not future parted-based code + <youpi> phcoder: I understand that for the offset ==0 thing + <youpi> but I didn't understand the phrase you wrote just after that + <phcoder> youpi: file_get_storage gives back a name. If this name is the + same as the partition we requested in the first place then it's current + code + <youpi> ah, ok + <youpi> yes, if the name is the same, it means it's not actually a + partition + <phcoder> youpi: current gnumach code makes fake devices out of partitions + <youpi> yes + <phcoder> youpi: with settrans command you told, I get num_ints = 0 + <youpi> phcoder: odd, I do get information, e.g.: + <youpi> hurd:/tmp# settrans -c /tmp/mysd0s1 /hurd/storeio -T typed + part:1:device:sd0 + <youpi> hurd:/tmp# storeinfo mysd0s1 + <youpi> device (0x200): sd0: 512: 83905: 42959360: 63+83905 + <phcoder> storeinfo: myhd0s1: Operation not supported + <youpi> do you actually have an hd0 device? + <phcoder> yes + <phcoder> youpi: I typed parted instead of part + <phcoder> Now it works + <youpi> good :) + <phcoder> youpi: what is expected timeline on migration to part interface? + <youpi> there's no real timeline + <youpi> like everything, it'll happen when somebody actually looks at how + to achieve it + <youpi> perhaps it'll be easy, perhaps not. IIRC there is still an issue + with the swapper + <phcoder> youpi: sounds like we're stuck will fallback code for at least + couple of years + <youpi> possibly, entirely depends on people taking the task + <youpi> if that becomes really pressing at some point, I'll have to do it, + but of course, I can not magically do everything in a glimpse + <phcoder> youpi: it's not pressing but just be aware that unusual + partitioning is likely to fail. Probably not huge issue. As to its place + in our code it's not ideal but it's not the only case of suboptimal + construction for specific systems (what we had to do because of Linux + caching is terrifying). I'm not going to make hurd code a scapegot of + more generic problem + <phcoder> youpi: and since we very rarely drop support this code is + probably stuck for good + <youpi> as long as it's not used whenever we get to move to parted-based + partitioning, it's not too bad + <phcoder> youpi: and Mac OS X/Darwin case is even worse. Apparently they + deprecated their *BSD functions (which probably don't work since they + don't use BSD labels) without giving any replacement. |