From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 25 Sep 2013 21:45:38 +0200 Subject: IRC. --- hurd/libstore/part.mdwn | 133 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 130 insertions(+), 3 deletions(-) (limited to 'hurd/libstore') 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 + + Hello, guys. Is there a way to know where partition starts on + hurd. E.g. given hd0s1 get "2048 sectors" + yes, it's the storeinfo RPC + let me find you a pointer + 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 ... + phcoder: Mmm, I guess you never got the userland-part.patch + upstream + ah, yes ,you did + I mean the find_hurd_root_device function + grub was previously using file_get_storage_info + youpi: find_hurd_root_Device/file_get_storage info is about + translating / -> /dev/hd0s1. Current problem is in step hd0s1 -> + hd0,msdos1 + yes, but iirc file_get_storage_info might work for hd0s1 itself + I see, let me try this + youpi: file_get_storage gives offset=0 size=partition size + (file_get_storage) damn + and name=hd0s1 + ah, that might be because we're still using in-kernel partition + table, instead of the parted partition table + looks like file_get_storage would be useful to get block size + though + 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? + 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 + I don't think there is any ioctl/RPC to get the kernel partition + table + youpi: is it using Linux partition code with some glue? + phcoder: the kernel partition table, yes + 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 + I know + that's why we want to migrate to the parted-based partition table + support + (which also brings us much better support than the old linux2.0 + code :) ) + youpi: I've looked into code and must say that I dislike what I + see: partitions handled in ide/ahci/sd/... + phcoder: which code? + youpi: gnumach + sure, that's not what we want in the end + grep -r start_sect + it's just the legacy linux way of doing partition support + Well Linux at least gives a meaningful ioctl + couldn't find any hint of it in gnumach + we didn't bother to add one since the parted way is supposed to be + what we have in the end + youpi: I can't make our code follow sth that might be the case in + the future + why not? + that's the way we will go + it's not just hypothetic + we just can't continue maintaining disk drivers in the kernel + so it won't be in the kernel + youpi: if I do then GRUB won't work on current GNU/Hurd anymore + can't you also keep the old code? + as a fallback when the proper way does not work (yet) + More hairs... :( + How do I check for it? offset == 0 isn't proper as partitions may + start at 0 + but checking than name still refers to partition is probably the + right way + I don't see what you mean + (about name) + youpi: I mean that we need a way to know that current code is + used and not future parted-based code + phcoder: I understand that for the offset ==0 thing + but I didn't understand the phrase you wrote just after that + 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 + ah, ok + yes, if the name is the same, it means it's not actually a + partition + youpi: current gnumach code makes fake devices out of partitions + yes + youpi: with settrans command you told, I get num_ints = 0 + phcoder: odd, I do get information, e.g.: + hurd:/tmp# settrans -c /tmp/mysd0s1 /hurd/storeio -T typed + part:1:device:sd0 + hurd:/tmp# storeinfo mysd0s1 + device (0x200): sd0: 512: 83905: 42959360: 63+83905 + storeinfo: myhd0s1: Operation not supported + do you actually have an hd0 device? + yes + youpi: I typed parted instead of part + Now it works + good :) + youpi: what is expected timeline on migration to part interface? + there's no real timeline + like everything, it'll happen when somebody actually looks at how + to achieve it + perhaps it'll be easy, perhaps not. IIRC there is still an issue + with the swapper + youpi: sounds like we're stuck will fallback code for at least + couple of years + possibly, entirely depends on people taking the task + 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 + 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 + youpi: and since we very rarely drop support this code is + probably stuck for good + as long as it's not used whenever we get to move to parted-based + partitioning, it's not too bad + 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. -- cgit v1.2.3