1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
[[!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]]
## [[service_solahart_jakarta_selatan__082122541663/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.
|
