Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391307 > unrolled thread

[PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree Douglas Anderson <dianders@chromium.org> - 2016-04-29 19:40 +0200
    [PATCH v2 1/4] Documentation: mmc: Document mmc aliases Douglas Anderson <dianders@chromium.org> - 2016-04-29 19:40 +0200
    [PATCH v2 2/4] mmc: read mmc alias from device tree Douglas Anderson <dianders@chromium.org> - 2016-04-29 19:40 +0200
    [PATCH v2 4/4] ARM: dts: rockchip: Add mmc aliases for rk3288 platform Douglas Anderson <dianders@chromium.org> - 2016-04-29 19:40 +0200
    Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Rob Herring <robh+dt@kernel.org> - 2016-04-29 20:20 +0200
      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 21:40 +0200
        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 22:00 +0200
          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 22:10 +0200
    Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 20:20 +0200
      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 21:50 +0200
        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 22:00 +0200
          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 22:10 +0200
            Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 23:20 +0200
              Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 23:40 +0200
                Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 00:00 +0200
                  Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-30 00:00 +0200
                    Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 00:20 +0200
                      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-30 00:30 +0200
                        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 00:50 +0200
                          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-30 01:10 +0200
                            Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Peter Hurley <peter@hurleysoftware.com> - 2016-04-30 02:00 +0200
                              Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Peter Hurley <peter@hurleysoftware.com> - 2016-04-30 02:40 +0200
                                Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-30 04:30 +0200
                                Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 10:40 +0200
                            Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Rob Herring <robh+dt@kernel.org> - 2016-04-30 15:30 +0200
                      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Javier Martinez Canillas <javier@dowhile0.org> - 2016-04-30 00:50 +0200
                        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 12:50 +0200
                          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Trent Piepho <tpiepho@kymetacorp.com> - 2016-05-03 21:30 +0200
              Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 23:40 +0200
            Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 23:20 +0200
      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Pavel Machek <pavel@ucw.cz> - 2016-05-04 09:20 +0200
        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Rob Herring <robh+dt@kernel.org> - 2016-05-04 14:30 +0200
          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Pavel Machek <pavel@ucw.cz> - 2016-05-04 14:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1391533 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On 04/29/2016 04:01 PM, Doug Anderson wrote:
> * serial allows numbering devices by alias.

Which is in fact a total nightmare.

While stable device order is mandatory in serial because of
console command line parameters and existing userspace expectations,
it is the number one barrier to providing a shared ttyS namespace
for mixed uart platforms.

Stable device order has a very real (and often unforeseen) maintenance
burden.

For example, I noticed these patches are strictly for DT.
I'm assuming that's because guaranteeing stable device order for
mmc in general is more difficult; eg., by performing minimal scan
serially and more expensive portion of the probe async.

Regards,
Peter Hurley

[toc] | [prev] | [next] | [standalone]

#1391544 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On 04/29/2016 05:03 PM, Doug Anderson wrote:
> Hi,
> 
> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
> 
>     On 04/29/2016 04:01 PM, Doug Anderson wrote:
>     > * serial allows numbering devices by alias.
> 
>     Which is in fact a total nightmare.
> 
>     While stable device order is mandatory in serial because of
>     console command line parameters and existing userspace expectations,
>     it is the number one barrier to providing a shared ttyS namespace
>     for mixed uart platforms.
> 
>     Stable device order has a very real (and often unforeseen) maintenance
>     burden.
> 
> 
> Interesting. I wonder if these burdens are unique to serial or shared
> by all the other subsystems that allow ordering? Maybe this is all
> because of legacy reasons?

Well, the specific issue is certainly unique to serial.
But what I was suggesting is that 5 years from now, these patches
could be the "legacy reasons" in mmc.

FWIW, there is already a defacto expectation by boot configurations in the
field that a given mmc block device is stable across boots. The reality
is that 100000's of kernel command lines look like:

	root=/dev/mmcblk0p2

This was a recent regression fixed by Ulf in commit 9aaf3437aa72
("mmc: block: Use the mmc host device index as the mmcblk device index")


> Note that for MMC devices we wouldn't be asserting that _every_
> device has a stable order. Only those known at boot.
> 
> 
>     For example, I noticed these patches are strictly for DT.
>     I'm assuming that's because guaranteeing stable device order for
>     mmc in general is more difficult; eg., by performing minimal scan
>     serially and more expensive portion of the probe async.
> 
> 
> Presumably if there were another system similar to DT where we knew
> all the possible built-in devices right at boot then we could
> extend.
> 
> ...but yes, obviously this wouldn't be a sane thing to do for
> anything probable like PCI or USB.

SCSI does. Here's what Linus said:

"So the *simple* model is to just scan the devices minimally serially,
and allocate the names at that point (so the names are reliable
between boots for the same hardware configuration). And then do the
more expensive device setup asynchronously (ie querying device
information, spinning up disks, whatever - things that can take
anything from milliseonds to several seconds, because they are doing
actual IO). So you'd do some very basic (and _often_ fairly quick)
operations serially, but then try to do the expensive parts
concurrently.

The SCSI layer actually goes a bit further than that: it has a fairly
asynchronous scanning thing, but it does allocate the actual host
device nodes serially, and then it even has an ordered list of
"scanning_hosts" that is used to complete the scanning in-order, so
that the sysfs devices show up in the right order even if things
actually got scanned out-of-order. So scans that finished early will
wait for other scans that are for "earlier" devices, and you end up
with what *looks* ordered to the outside, even if internally it was
all done out-of-order.
"

Regards,
Peter Hurley

[toc] | [prev] | [next] | [standalone]

#1391566 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Hi,

On Fri, Apr 29, 2016 at 5:31 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On 04/29/2016 05:03 PM, Doug Anderson wrote:
>> Hi,
>>
>> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>>
>>     On 04/29/2016 04:01 PM, Doug Anderson wrote:
>>     > * serial allows numbering devices by alias.
>>
>>     Which is in fact a total nightmare.
>>
>>     While stable device order is mandatory in serial because of
>>     console command line parameters and existing userspace expectations,
>>     it is the number one barrier to providing a shared ttyS namespace
>>     for mixed uart platforms.
>>
>>     Stable device order has a very real (and often unforeseen) maintenance
>>     burden.
>>
>>
>> Interesting. I wonder if these burdens are unique to serial or shared
>> by all the other subsystems that allow ordering? Maybe this is all
>> because of legacy reasons?
>
> Well, the specific issue is certainly unique to serial.
> But what I was suggesting is that 5 years from now, these patches
> could be the "legacy reasons" in mmc.
>
> FWIW, there is already a defacto expectation by boot configurations in the
> field that a given mmc block device is stable across boots. The reality
> is that 100000's of kernel command lines look like:
>
>         root=/dev/mmcblk0p2
>
> This was a recent regression fixed by Ulf in commit 9aaf3437aa72
> ("mmc: block: Use the mmc host device index as the mmcblk device index")

Ah.  Well, in this case it sounds like we've already got an
expectation of stable numbering from boot to boot.  I had missed Ulf's
patch, so I guess part 3 of my series isn't actually needed and can be
dropped.

So it's just a question of whether we allow people to manually specify
via device tree.


Note: if we really think using root=/dev/mmcblkNpM is a bad idea then
we should deprecate it and yell about it in the boot log.  Then 5 (or
20) years down the road we could remove the feature when the legacy
burden become a pain.  Note that even if we deprecated
root=/dev/mmcblkNpM I'd still love to see the numbering be consistent
to help folks parse dmesg.


Thanks for your thoughts!


-Doug

[toc] | [prev] | [next] | [standalone]

#1391582 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 05:31:31PM -0700, Peter Hurley wrote:
> FWIW, there is already a defacto expectation by boot configurations in the
> field that a given mmc block device is stable across boots. The reality
> is that 100000's of kernel command lines look like:
> 
> 	root=/dev/mmcblk0p2

Thankfully, MMC does generally give a stable naming across reboots -
I have platforms with eMMC and SD (eg, the SDP4430 board which is in
the test farm) and only when things change in the kernel does the
MMC device name change.

Changes in device ordering can be provoked by the order in which
entries in the DT file appear, and hence the order in which the host
SD interfaces are probed by the kernel.

When it changed, I switched from using the device specifier to using
a UUID.  Now I have no problems since I no longer care which MMC
block device ends up as the SD card.

The kernel there is TFTP'd too.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1391623 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 6:01 PM, Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Fri, Apr 29, 2016 at 3:44 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> My reply would be... why should MMC have special handling that no
>> other subsystem has?
>
> No other subsystem?
>
> * i2c allows numbering devices by alias
> * rtc allows numbering devices by alias.
> * serial allows numbering devices by alias.
> * spi allows numbering devices by alias.
> * watchdog allows numbering devices by alias.
>
> ...at least that's my impression doing a grep for of_alias_get_id(),
> which I suggested earlier in this thread but apparently wasn't done.

IMO, we should remove most or all of these not add more. We shoud move
to identifying devices by other OS independent means. Peter already
pointed out why serial is a problem.

Rob

[toc] | [prev] | [next] | [standalone]

#1391509 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

Hello Russell,

On Fri, Apr 29, 2016 at 6:16 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 02:56:38PM -0700, Doug Anderson wrote:
>> Russell,
>>
>> On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
>> > [didn't read most of your reply]
>> >
>> >> Really I just reposted it several times because I notice that you seem
>> >> to ignore many points of my emails.  I was really hoping to get you to
>> >> address this point.  I notice that you still didn't.  Either you are
>> >> just trying to annoy me, or you don't have an answer to how my patch
>> >> series hurts you.
>> >
>> > I don't see you treating Rob with the same contempt that you have
>> > treated me in this thread, despite Rob and myself both telling you
>> > basically the same thing.
>>
>> Rob wrote a nice thoughtful reply and I tried to give a nice
>> thoughtful reply back to him.  He raised some good points and I raised
>> some good points back to him.  I look forward to his future thoughts
>> on the topic.
>
> Meanwhile, I've pointed out that you appear to be coming from a
> misunderstanding (that's certainly clear because you believed
> initially that grub did something it doesn't), showing that the
> "problem" you have is no different from the majority of other
> systems running Linux, and you treat me with contempt.
>
> What are you going to do to resolve this?
>

Maybe a third opinion could make this conversation constructive again.

I think Doug's point is that using a UUID or labels for consistency is
orthogonal to having a deterministic numbering for MMC devices. And I
agree with his point of view for what is worth.

I understand that this not true for other systems and peripherals but
in the specific case of MMC, the changes are minimal as Doug's patches
have shown and even the technical manual of SoCs has an enumeration to
refer each SD/MMC slot.

So I think is fair to say that SD/MMC is different than say USB mass
storage devices as you mentioned, and having a consistent numbering is
very helpful for diagnostics and debugging purposes IMHO.

BTW, I use labels in all my systems because as you said it's nice to
be able to swap cards and not change the bootloader env vars, but I
see how having a deterministic numbering could be useful to others.

Best regards,
Javier

[toc] | [prev] | [next] | [standalone]

#1391590 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 06:42:35PM -0400, Javier Martinez Canillas wrote:
> Maybe a third opinion could make this conversation constructive again.
> 
> I think Doug's point is that using a UUID or labels for consistency is
> orthogonal to having a deterministic numbering for MMC devices. And I
> agree with his point of view for what is worth.

Yes, it may be orthogonal, but there are two issues here:

1. How does the system know which MMC device to mount for its rootfs.

This is the point that I've picked up on, which has been solved for
years, and actually pre-dates MMC support in the kernel, and that is
mount by UUID.

The kernel itself has no support for mount-by-label, which is normally
solved by using an initramfs, which contains programs such as mount
etc which will scan the block devices looking for an appropriately
labelled filesystem.  Label has slightly more issues since its possible
that you could end up with two filesystems with the same label (eg, on
x86, you're migrating your disks, and you plug in a disk which has a
label of "/" but is not your intended rootfs.)

Of course, any scheme which relies on an identifier on the disk may
result in some kind of clash if another partition/disk has the same
identifier.

2. The identifier found in kernel messages for each MMC device.

This is where Doug and myself disagree.  I don't see this as a big
problem - the big problem is (1) above, which is the one which can
lead to a non-functional system.  I believe that the actual name
that we end up with is a cosmetic issue.

What I've been trying to point out is that the same cosmetic issue
occurs elsewhere in the kernel, particularly with disks on SATA
interfaces.  I've lost count of the number of times that my IDE
disks on one of my machines have changed between /dev/hda, /dev/hdc,
/dev/sda, /dev/sdc, etc.  Thankfully, these are part of a raid
array, and they are always constructed to appear as /dev/md* devices
which are the devices that are mounted.

The device names that they end up with depend on which drivers are
built-in to the kernel, and the order in which the device drivers
and devices are probed.  There's no way to tell the kernel "I want
PCI card X socket Y to be _this_ device name" and that's a concious
decision that was made years ago.

However, it's a cosmetic issue - reading the log reveals which is
which, and MMC is no different - the information required is in the
log.

Here's some material on the problem:

http://www.tldp.org/HOWTO/Partition/devices.html
http://tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x99.html
https://lkml.org/lkml/1997/5/4/54
http://marc.info/?l=linux-raid&m=113595057816321&w=2

The first two show that it's well understood (and documented) that
storage devices are dynamically assigned and variable.

The third is an example of how old this problem is - almost twenty
years old, and it hasn't been "solved" on x86 except by using UUID/
labels.

The forth is an example of the "problem" that this dynamic device
assignment causes, and again shows that kernel folk have chosen
not to solve it by way of the problem still existing today.

I guess I don't see it as much of problem because I've been doing
this for over a decade.

Now, thinking outside the box - if it's desirable for eMMC to be
treated differently from regular MMC slots, maybe the solution to
this problem is to have eMMC occupy a separate namespace, rather
than using the /dev/mmcblk* namespace.  IOW, /dev/emmc* ?

The /dev/mmcblk* namespace was designed (by me) to be dynamic,
because MMC (not SD) bus structure allows for multiple cards on the
same MMC host interface, much like a SCSI bus allows for multiple
devices on the same cable.  Hence, tying individual mmcblkN to
the mmcN host interface is wrong.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1393758 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Sat, 2016-04-30 at 11:48 +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 29, 2016 at 06:42:35PM -0400, Javier Martinez Canillas wrote:
> > Maybe a third opinion could make this conversation constructive again.

And maybe a forth.

> > I think Doug's point is that using a UUID or labels for consistency is
> > orthogonal to having a deterministic numbering for MMC devices. And I
> > agree with his point of view for what is worth.
> 
> Yes, it may be orthogonal, but there are two issues here:
> 
> 1. How does the system know which MMC device to mount for its rootfs.
> 
> This is the point that I've picked up on, which has been solved for
> years, and actually pre-dates MMC support in the kernel, and that is
> mount by UUID.

What about eMMC boot blocks and replay protected memory block?  These
are special sub-device like features of eMMC that provide storage from
different areas than the normal flash.  The kernel names them something
like "/dev/mmcblk0boot0" and "/dev/mmcblk1rpmb".

They typically don't have partition tables and in fact the kernel
xplicitly does not scan them for a partition table.  So how can they
have a UUID?

Suppose your device has two SD slots, neither with an SD card inserted
in it, one external and one internal behind a locked access panel.  They
serve different purposes.  How do you determine which is which via UUID
when they have no media?

> The kernel itself has no support for mount-by-label, which is normally
> solved by using an initramfs, which contains programs such as mount
> etc which will scan the block devices looking for an appropriately
> labelled filesystem.  Label has slightly more issues since its possible

But what is faster, using an initramfs that loads a working userspace
into RAM, scans the flash device for partition labels, determines the
device ID, and then switches to the real rootfs.  Or having the
bootloader, which already knows the partition the rootfs is in, tell the
kernel what device to mount from the beginning?

Which brings me to another reason for providing device enumeration
information via the device tree that isn't just about mounting the root
filesystem.

The bootloader will create an enumeration of devices so that it can
access them.  The kernel will also create an enumeration of the same
devices.  Should these enumerations be the same, or should they be
different?

Clearly there are advantages to the enumeration being the same.  It's
easier on users if device IDs can be the same between the two
environments, bootloader and kernel, the device can be accessed from.

It also makes it easier if information about a device needs to be passed
from the bootloader to the kernel.  This could be the root filesystem,
but that's not the only thing.  Console serial port is another.  But we
could also want to kernel to know which of the SoC's ports is connected
to the blank eMMC chip it should create a partition table on and format,
and which is connected to the SD card it should store logging data to.

I can't think of any advantage of the enumerations being different.

So if identical enumerations are desirable, how to achieve it?

One way would be to have the bootloader create its enumeration and then
throw it away when the kernel boots.  The the kernel creates a new
enumeration from scratch, using a different system with different code
and a different design, that happens to create the same enumeration that
the bootloader did.  This seems like a bad design to me.  Two different
code bases will need to kept in sync, to always to the same thing in a
different way.  It will be hard to avoid bugs from corner cases that
fail to produce the same enumerations.

Another way would be to have the bootloader tell the kernel what it
enumerated and then have the kernel use this enumeration.  This avoids
the need to keep two code bases in sync.  It avoids bugs where they fail
to produce the same enumeration.

And how to do this pass the enumeration from the bootloader to the
kernel?  The same way all other information from the bootloader is
passed to the kernel, via the device tree.

The alias system that already exists allows the bootloader to tell the
kernel about enumerations it has already created, which it must do since
it runs before the kernel, and would like the kernel to continue to use.

So this isn't just about finding the root filesystem.  It's about
passing enumeration information from the bootloader to the kernel.

[toc] | [prev] | [next] | [standalone]

#1391448 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 02:17:45PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Apr 29, 2016 at 2:13 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 01:04:48PM -0700, Doug Anderson wrote:
> >> Russell,
> >>
> >> On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> >> * Presumably on a PC you've got an extra bit in the middle (like grub
> >> >> or something like that) that can help you resolve your UUIDs even if
> >> >> you get your kernel from somewhere else.
> >> >
> >> > You are over-estimating what grub does.  Grub doesn't resolve UUIDs at
> >> > all.  Grub just passes the kernel arguments in its configuration file
> >> > for the entry it is booting to the kernel.  It's a static configuration
> >> > found in /boot/grub/grub.conf.
> >> >
> >> > It doesn't probe devices for UUIDs.
> >>
> >> OK.  The point was: if folks on PCs have a workflow that works for
> >> them, wonderful.  That workflow doesn't work so great for me.  My
> >> workflow doesn't hurt them.  Why is it bad?
> >
> > This discussion is over, since you're not willing to actually discuss
> > it (illustrated by you cutting and pasting this same thing four
> > times in your reply.)
> >
> > My NAK stands until such time that you can partake in a reasonable
> > discussion.
> 
> The point of pasting it several times was that you'd answer it.
> Apparently that failed.
> 
> Perhaps you could answer the question I posed?

No, because you haven't taken the time to think and consider my
reply, which gives you insight into how your "problem" is no
different from the situation that everyone else has, where it
isn't a problem.

I think the "problem" here is that you've got used to coreboot
doing something that very few other boot loaders do, namely it
automatically extracting a rootfs UUID for you.  The rest of the
world doesn't have that luxury.

So, instead, you want to stuff more code into the kernel to work
around what you think is a problem - a problem which seems to be
unique to yourself.

The UUID and label solutions were created by x86 people to work
around exactly this dynamic device problem, and as my previous
replies have shown, it is superior to fixing the device assignment
as you're trying to do.

However, I don't expect that you'll like this answer, and you'll
probably just re-post your same question after each and every
paragraph rather than considering whether the already existing
solutions could solve your "problem".  So I'm just wasting my time.

This is my last reply.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1391432 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri, Apr 29, 2016 at 01:04:48PM -0700, Doug Anderson wrote:
> Russell,
> 
> On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> * Presumably on a PC you've got an extra bit in the middle (like grub
> >> or something like that) that can help you resolve your UUIDs even if
> >> you get your kernel from somewhere else.
> >
> > You are over-estimating what grub does.  Grub doesn't resolve UUIDs at
> > all.  Grub just passes the kernel arguments in its configuration file
> > for the entry it is booting to the kernel.  It's a static configuration
> > found in /boot/grub/grub.conf.
> >
> > It doesn't probe devices for UUIDs.
> 
> OK.  The point was: if folks on PCs have a workflow that works for
> them, wonderful.  That workflow doesn't work so great for me.  My
> workflow doesn't hurt them.  Why is it bad?

This discussion is over, since you're not willing to actually discuss
it (illustrated by you cutting and pasting this same thing four
times in your reply.)

My NAK stands until such time that you can partake in a reasonable
discussion.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1394031 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Fri 2016-04-29 19:12:48, Russell King - ARM Linux wrote:
> On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:
> > This series picks patches from various different places to produce what
> > I consider the best solution to getting consistent mmc and mmcblk
> > ordering.
> > 
> > Why consistent ordering and why not just use UUIDs?  IMHO consistent
> > ordering solves a few different problems:
> 
> NAK.  Really.  Use UUIDs, that's the proper solution here.

Except that UUIDs do not solve the problem.

You have just booted of nfsroot, and you want to format u-SD card in
the external slot. How do you do that?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1394232 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Wed, May 4, 2016 at 2:18 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Fri 2016-04-29 19:12:48, Russell King - ARM Linux wrote:
>> On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:
>> > This series picks patches from various different places to produce what
>> > I consider the best solution to getting consistent mmc and mmcblk
>> > ordering.
>> >
>> > Why consistent ordering and why not just use UUIDs?  IMHO consistent
>> > ordering solves a few different problems:
>>
>> NAK.  Really.  Use UUIDs, that's the proper solution here.
>
> Except that UUIDs do not solve the problem.
>
> You have just booted of nfsroot, and you want to format u-SD card in
> the external slot. How do you do that?

The same way you format a USB stick when you insert it.

If you have built-in versus removable, then we should expose that
information to userspace rather than some arbitrary encoding in DT
that 0 means built-in and 1 means removable. Or if you have multiple
slots, then use "label" to provide meaningful slot names.

Rob

[toc] | [prev] | [next] | [standalone]

#1394260 — Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

On Wed 2016-05-04 07:25:42, Rob Herring wrote:
> On Wed, May 4, 2016 at 2:18 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Fri 2016-04-29 19:12:48, Russell King - ARM Linux wrote:
> >> On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:
> >> > This series picks patches from various different places to produce what
> >> > I consider the best solution to getting consistent mmc and mmcblk
> >> > ordering.
> >> >
> >> > Why consistent ordering and why not just use UUIDs?  IMHO consistent
> >> > ordering solves a few different problems:
> >>
> >> NAK.  Really.  Use UUIDs, that's the proper solution here.
> >
> > Except that UUIDs do not solve the problem.
> >
> > You have just booted of nfsroot, and you want to format u-SD card in
> > the external slot. How do you do that?
> 
> The same way you format a USB stick when you insert it.

Well, and that actually brings related question "how do you format the
right USB stick if you have 5 of them connected". PCs don't have good
solution, but that does not mean it can't be solved.

And no, its not really the same. At least in N900 case, I'm not really
sure if you are expected to manipulate the u-SD card while the system
is on. It is under battery cover.

> If you have built-in versus removable, then we should expose that
> information to userspace rather than some arbitrary encoding in DT
> that 0 means built-in and 1 means removable. Or if you have multiple
> slots, then use "label" to provide meaningful slot names.

Yes, labels would be nice. Plus the slot numbers should be stable, so
that booting does not randomly break.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web