[[!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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!meta title="part store"]] `part.c` Written by Neal in 2001, 2002. Useful if the microkernel / [[DDE]] / [[microkernel/mach/gnumach/ports/Xen]] doesn't export *partition devices*, but only *raw* devices. Neal: > The motivation was to be able to evict the partitioning logic from Mach. # Booting A similar problem is described in [[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented. # Open Issues ## 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.