Re: ZZZ and extra mountpoints
Mark Kettenis wrote: > > I tend to agree that the complexity of this is out of scope for > > man pages. Understanding this properly requires reading books > > about computer architecture first. > > So I would phrase this as something like "device that the OpenBSD > kernel considers removable". And also note that the opposite happens > as well: there are devices that our kernel considers non-removable > that are in fact removable. For example ExpressCard devices, which > are considered non-removable since they are indistinguishable from > normal PCIe devices. Now you've really stepped in it. I have an expresscard storage device. At suspend time, it gets powered off. It detaches and reattaches at resume time. Any partition mounts are forceably unmounted when that happens. Would softraid work in those conditions? I don't know, and I don't care. I want us all to take a step back here. Some of you want to describe the situation as accurately as possible, and obviously then our users will take what they read as promises that it works that way, it won't change, and they can build complicated layers on top of it. Describing it accurately will only encourage more people to create fragile configurations, write blogs about it, and thus encourage even more people to create more broken situations. I think that procedure is hogwash. A more accurate picture is that the machines don't provide us with sufficient information, and therefore we will do whatever it takes in the kernel to ensure that suspend/resume works for 99% of the people, and the other 1% of people will lose. If people start constructing complicated scenarios, the number of losing cases will increase.
Re: ZZZ and extra mountpoints
> Date: Fri, 21 Oct 2022 20:11:49 +0200 > From: Stefan Sperling > > On Fri, Oct 21, 2022 at 06:46:14PM +0100, Jason McIntyre wrote: > > pluggable? The word "removable" is probably a better choice as this is the language used by the ACPI and device tree standards. > It really is a very machine-specific question. It depends > on how the manufaturer decided to connect devices to the > mainboard, which is not always possible to tell from the > perspective of software which runs on the machine. We probably can do a better job than we do now, but there will always be machines where the firmware lies to us. > There can be flash disks soldered into laptops which are > connected via an sdmmc bus, which will be detached because > they look just like a pluggable SD card. Actually that is a case where we do take into account what the firmware tells us. In ACPI there is a _RMV() method that will return 0 if a device cannot be removed. And device trees have a "non-removable" property. But that information isn't always correct and there are weird corner cases like eMMC modules that aren't soldered but are not quite so removable as a pluggable SD card. > There are machines with internal USB disks, e.g. the Edge > Router lite, which, granted, is not an amd64 machine and > does not suspend/resume. But a similar embedded amd64 with > a USB slot for internal disk could exist. Perhaps as a custom > build where someone plugged a USB stick into a USB header on > the motherboard. Certainly feasible. > > Several laptops I own have internal webcams on the USB bus. > Which will be detached because there isn't a generic way to > tell whether they are on an internal or external USB port. > And perhaps the entire USB bus will be powered down when > the host controller goes to sleep, and all connected devices > will lose power. Losing power isn't reall what's relevant. Most devices should lose power during suspend/hibernate. > I tend to agree that the complexity of this is out of scope for > man pages. Understanding this properly requires reading books > about computer architecture first. So I would phrase this as something like "device that the OpenBSD kernel considers removable". And also note that the opposite happens as well: there are devices that our kernel considers non-removable that are in fact removable. For example ExpressCard devices, which are considered non-removable since they are indistinguishable from normal PCIe devices.
Re: ZZZ and extra mountpoints
Stefan Sperling wrote: > And perhaps the entire USB bus will be powered down when > the host controller goes to sleep, and all connected devices > will lose power. but oh ... the situation is even more complicated: There are situations where a machine won't suspend because a bus has power-draw on it, because we didn't evict the sub-devices, so some code kicks devices off, otherwise you can't suspend. Now hibernate could be a bit different, but who is going to write this code and validate it on all machines?? Not me. Not anyone. But oh, we can try to describe this strange situation in a manual page which noone will read before they hit the situation of a device disconnecting during suspend? So helpful /sarc.
Re: ZZZ and extra mountpoints
On Fri, Oct 21, 2022 at 06:46:14PM +0100, Jason McIntyre wrote: > pluggable? It really is a very machine-specific question. It depends on how the manufaturer decided to connect devices to the mainboard, which is not always possible to tell from the perspective of software which runs on the machine. There can be flash disks soldered into laptops which are connected via an sdmmc bus, which will be detached because they look just like a pluggable SD card. There are machines with internal USB disks, e.g. the Edge Router lite, which, granted, is not an amd64 machine and does not suspend/resume. But a similar embedded amd64 with a USB slot for internal disk could exist. Perhaps as a custom build where someone plugged a USB stick into a USB header on the motherboard. Certainly feasible. Several laptops I own have internal webcams on the USB bus. Which will be detached because there isn't a generic way to tell whether they are on an internal or external USB port. And perhaps the entire USB bus will be powered down when the host controller goes to sleep, and all connected devices will lose power. I tend to agree that the complexity of this is out of scope for man pages. Understanding this properly requires reading books about computer architecture first.
Re: ZZZ and extra mountpoints
Jason McIntyre wrote: > > It is extremely complicated, there is no way to accurately explain > > in user-speak what devices detach and what devices don't detach. > > > > pluggable? Sorry, that is completely untrue. What kind of plug? A USB plug? A MMC plug? A PCI plug? A MINI-PCIE plug? A docking station which has both USB or PCI plugins? An internal USB plug? How about an internal SDMMC device? And how about thunderbolt? How about an extern scsi chassis with it's own power? I could probably write a 5-sentence paragraph delineating the boundaries with great precision and yet the people reading it would find they still cannot discern exactly what devices will be detached. "If it loses power" isn't accurate either. Some of our drivers even self-protect themselves by FORCING a detach of their children. you all seem to want a single word or a simple sentence, but I'm sorry it isn't simple at all. > > And if we can't write a correct sentence for that, maybe we should realize > > we don't need to? > > > > Make a proposal. > > > > i agree that the original proposal was wrong. if anything, you'd maybe > want to know, for example, how to make it that you *were* asked for your > password when resuming an encrypted mount. that seems more pertinent to > softraid(4) than apm(8). I think that is nonsense. These subsystems were not designed to work together in the way that people _now believe_ they should work together. Now they want to document small little edges of their experience without understanding how the layers of different code actually works? It is trying to document based upon ignorance.
Re: ZZZ and extra mountpoints
On Fri, Oct 21, 2022 at 10:34:23AM -0600, Theo de Raadt wrote: > Sol??ne Rapenne wrote: > > > I agree my sentence isn't good enough or is too much, but I think ZZZ > > explanations isn't enough in its current form > > Maybe it is lacking. But your previous diff didn't help anyone. > > > from your reply I got > > information such as external devices that wasn't described in the man > > page. > > External devices have to get detached. They lose their configuration > because they lose their power. > > The problem is that it is very difficult to explain to users, in a > precise way, what an 'external device' is versus an 'internal device'. > > It is extremely complicated, there is no way to accurately explain > in user-speak what devices detach and what devices don't detach. > pluggable? > And if we can't write a correct sentence for that, maybe we should realize > we don't need to? > > Make a proposal. > i agree that the original proposal was wrong. if anything, you'd maybe want to know, for example, how to make it that you *were* asked for your password when resuming an encrypted mount. that seems more pertinent to softraid(4) than apm(8). jmc
Re: ZZZ and extra mountpoints
Solène Rapenne wrote: > I agree my sentence isn't good enough or is too much, but I think ZZZ > explanations isn't enough in its current form Maybe it is lacking. But your previous diff didn't help anyone. > from your reply I got > information such as external devices that wasn't described in the man > page. External devices have to get detached. They lose their configuration because they lose their power. The problem is that it is very difficult to explain to users, in a precise way, what an 'external device' is versus an 'internal device'. It is extremely complicated, there is no way to accurately explain in user-speak what devices detach and what devices don't detach. And if we can't write a correct sentence for that, maybe we should realize we don't need to? Make a proposal.
Re: ZZZ and extra mountpoints
I disagree with this sentence. The machine is unhiberated in the same way that an unsuspend happens. EVERYTHING is as it was before, except for one thing: Devices which are not known to be part of the machine, will have become detached, and if/when they reattach, configuration of them will be missing. But that is not what you are describing here, in fact it is wrong, because a softraid partition on a usb device (or similar) will be gone. So you are adding a detail which is unneccesary, but also inaccurate. If you add this sentence, the next one sentence someone will propose will likely be "network configuration" remains the same. Then, a sentence that your programs are still running. And on and on, trying to explain that this isn't like a reboot. But all of that "state-maintained" information is already implied, because that is what suspend/resume and hibernate/unhibernate means. Solène Rapenne wrote: > hi > > I'm using an dedicated encrypted partition for a mountpoint and I was > wondering what would happen if I use ZZZ and then resume. > > - will it work out of the box? > - will it fail because the softraid device won't exist? > - am I going to be asked the passphrase by my rc.local script? > > It turned it worked out of the box, which mean the partitions remains > unlocked. In my opinion it's worth documenting, however I'm really not > sure how to word this in apm(8), here is an attempt > > diff --git a/usr.sbin/apm/apm.8 b/usr.sbin/apm/apm.8 > index ed110e11f14..61d414da8f1 100644 > --- a/usr.sbin/apm/apm.8 > +++ b/usr.sbin/apm/apm.8 > @@ -105,6 +105,8 @@ boot will occur, followed by the reading of the saved > memory image. > The image will then be unpacked and the system resumed > at the point immediately after the hibernation request. > +This implies that extra encrypted partitions (like an > +external disk) will remain unlocked after the resume. > .It Fl z > Put the system into suspend (deep sleep) state. > .El >
Re: ZZZ and extra mountpoints
I think this adds nothing. It already states your system will be restored to its previous state, and so it will, as far as possible. Actually, specifically external (USB) disks, are probably *not* properly restored though... /Alexander On October 21, 2022 9:05:25 AM GMT+02:00, "Solène Rapenne" wrote: >hi > >I'm using an dedicated encrypted partition for a mountpoint and I was >wondering what would happen if I use ZZZ and then resume. > >- will it work out of the box? >- will it fail because the softraid device won't exist? >- am I going to be asked the passphrase by my rc.local script? > >It turned it worked out of the box, which mean the partitions remains >unlocked. In my opinion it's worth documenting, however I'm really not >sure how to word this in apm(8), here is an attempt > >diff --git a/usr.sbin/apm/apm.8 b/usr.sbin/apm/apm.8 >index ed110e11f14..61d414da8f1 100644 >--- a/usr.sbin/apm/apm.8 >+++ b/usr.sbin/apm/apm.8 >@@ -105,6 +105,8 @@ boot will occur, followed by the reading of the saved > memory image. > The image will then be unpacked and the system resumed > at the point immediately after the hibernation request. >+This implies that extra encrypted partitions (like an >+external disk) will remain unlocked after the resume. > .It Fl z > Put the system into suspend (deep sleep) state. > .El >
