Re: dkwedge: checksum before swapping?
mo...@rodents-montreal.org (Mouse) writes: >But that comment clearly indicates that _someone_ thought it >reasonable to checksum before swapping, so I can't help wondering what >use case that's appropriate for. It's a checksum over the 16bit words in native byte order. So when you access the words in opposite byte order, you need to swap the checksum too. Unlike the regular disklabel code (which ignores other-endian disklabels) the wedge autodiscover code will accept either. As for padding, the structure is nowadays defined with fixed size types and explicit padding fields, so we may still assume that the compiler won't add any further padding by itself.
dkwedge: checksum before swapping?
In sys/dev/dkwedge/dkwedge_bsdlabel.c, I find (and I see more or less
the same code in 5.2 and what cvsweb.n.o shows me)
static int
validate_label(mbr_args_t *a, daddr_t label_sector, size_t label_offset)
{
...
/*
* We have validated the partition count. Checksum it.
* Note that we purposefully checksum before swapping
* the byte order.
*/
...code that does indeed checksum before swapping...
}
Does anyone know what the intent of this is? The only reason I would
expect to see a byteswapped label is when it's written by a machine of
the other endianness, and in that case the checksum will be wrong
unless the label is swapped before checksumming (and even then only if
the compiler doesn't insert shims in the struct, not that it's likely
to given the present layout).
But that comment clearly indicates that _someone_ thought it
reasonable to checksum before swapping, so I can't help wondering what
use case that's appropriate for.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Per-descriptor state
On 2023-05-08 02:09, Johnny Billquist wrote: On 2023-05-08 01:30, David Holland wrote> On Fri, May 05, 2023 at 09:44:25PM -0400, Mouse wrote: > not nearly as > horrible as, say, the hack I once implemented where calling > wait4(0x456d756c,(int *)0x61746f72,0x4d616769,(struct rusage *)0x633a2d29) ^^ > would produce suitably magic effects. (This was on a 32-bit machine.) surely you mean 39! Hmm? "EmulatorMagic:-)" don't do it for you, you want "EmulatorMagic:=)" ? I wonder what the emoji " :=) " means... Double nose? Ok. I'm being very silly. I need to go to bed... :-) And I'm clearly half asleep already. Sorry... :-9 it was... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Per-descriptor state
On Mon, May 08, 2023 at 12:36:21AM +, David Holland wrote: > I... completely failed to recognize it as an emoji and assumed it was > supposed to be -9 to forcibly shut something down. emoji. smiley. yeah -- David A. Holland dholl...@netbsd.org
Re: Per-descriptor state
On Mon, May 08, 2023 at 02:09:07AM +0200, Johnny Billquist wrote: > > > not nearly as > > > horrible as, say, the hack I once implemented where calling > > > wait4(0x456d756c,(int *)0x61746f72,0x4d616769,(struct rusage > > > *)0x633a2d29) > > > > ^^ > > > would produce suitably magic effects. (This was on a 32-bit machine.) > > > > surely you mean 39! > > Hmm? > > "EmulatorMagic:-)" don't do it for you, you want "EmulatorMagic:=)" ? I... completely failed to recognize it as an emoji and assumed it was supposed to be -9 to forcibly shut something down. :-| -- David A. Holland dholl...@netbsd.org
Re: Per-descriptor state
On 2023-05-08 01:30, David Holland wrote> On Fri, May 05, 2023 at 09:44:25PM -0400, Mouse wrote: > not nearly as > horrible as, say, the hack I once implemented where calling > wait4(0x456d756c,(int *)0x61746f72,0x4d616769,(struct rusage *)0x633a2d29) ^^ > would produce suitably magic effects. (This was on a 32-bit machine.) surely you mean 39! Hmm? "EmulatorMagic:-)" don't do it for you, you want "EmulatorMagic:=)" ? I wonder what the emoji " :=) " means... Double nose? Ok. I'm being very silly. I need to go to bed... :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Per-descriptor state
On Fri, May 05, 2023 at 09:44:25PM -0400, Mouse wrote:
> >>> But I kind of think it'd be preferable to make a way to clone a
> >>> second independent struct file for the same socket than to start
> >>> mucking with per-descriptor state.
> >> [...] it should be easy to extend dup3() to make that possible [...]
> > If we were to add such a thing it should be called something else,
> > not dup, because it's a fundamentally different operation from dup
> > and we don't need people confusing them.
>
> Different? Some. But not very. It _is_ closely related to dup(). I
> don't think dup3() would be a horrible way to do it -
There's already a dup3(). But ignoring that... yes, it's quite
significant, it constructs a materially different kind of additional
reference. For everyone who knows the internal structure of
references, which is probably everyone reading this list, it's easy to
understand what the semantics are and what the difference between the
two operations; for everyone else, which is most of the world and most
of the people who will ever use the call, it is _not_ clear and if
the two cases aren't made overtly distinct they'll routinely mix them
up and get in trouble. Even if they are made overtly distinct you'll
still get bozos making wrong proclamations about them in places like
stackoverflow.
*puts on his "taught this to undergrads for many years" hat*
> not nearly as
> horrible as, say, the hack I once implemented where calling
> wait4(0x456d756c,(int *)0x61746f72,0x4d616769,(struct rusage *)0x633a2d29)
^^
> would produce suitably magic effects. (This was on a 32-bit machine.)
surely you mean 39!
> But, honestly, when I saw the idea my reaction was to make it a new
> operation to fcntl. F_REOPEN, say, since it's creating new per-open
> state. Or, if you want to be all overloady, how about
> open(0,O_REOPEN,existingfd)? It _is_ creating new per-open state, so
> open is in _some_ sense right.
>
> My choice, for what it's worth, would be fcntl, dup3 second, with
> O_REOPEN a distant third.
fcntl is inherently terrible and shouldn't get new ops or use cases
(there is absolutely no reason to prefer it to a new syscall except
for conservation of syscall numbers, which isn't a useful thing).
Should be something like reopen(fd, flags).
Or it could be open("/dev/fd/%d", flags); except that neither the
pathname nor the semantics of /dev/fd are reliably portable.
(...passing a fd as a 3rd argument to open is really horrible; that's
a mode_t, not a fd)
--
David A. Holland
dholl...@netbsd.org
Re: Per-descriptor state
On Thu, May 04, 2023 at 08:40:49AM -0400, Mouse wrote: > >> I can't think of any at all; to begin with it's limited to forks > >> that don't exec > [...] > > Well, except for libraries that open fds internally, without exposing > them to the calling code. Depending on the user case, they may want > them closed if the application forks. > > [...] > > Because one wants to exec a child process, maybe? If the fork is going to exec, O_CLOEXEC is sufficient; I can't think of any realistic situation where having a second reference to the same file for at most few extra milliseconds can actually hurt anything. -- David A. Holland dholl...@netbsd.org
Re: How to submit patches?
Like the OP I’ve experienced similar issues with X on some of my systems. Earlier versions of NetBSD (and Xorg) worked a bit better on configuring some of my setups. When Xorg was modified to try and reduce the need for an xorg.conf file things really messed up for me, but as Xorg has evolved over the last couple of years it has been getting better in this respect. Although I haven’t looked into the Xorg code, my feeling it is trying to use a combination of decoding the EDID and some set of internal tables. On my systems I’ve seen cases where setups that were in the EDID for my monitor didn’t show up during configuration and some cases where the opposite is true. I also see similar disconnects with what appear to be configurations listed in the x.log files which seem to be coming from internal tables, like the ones the OP is addressing with his modifications. There also seem to be some issues with things like blanking times and video placement on the monitor that I’ve had to adjust with MODELINES in my xorg.conf files that again appear to be addressed in the proposed modifications. Finally, for some reason I usually see fewer problems in getting my monitors configured when using various versions of Linux than I do with NetBSD when running on the same HW. I don’t know if these anomalies are in the Xorg configurations since both seem to use the same versions, or if the anomalies are a result of differences in the lower level drivers. In most cases I’ve been able to work around these by copying some of the MODELINES coming out of Linux and putting them in an xorg.conf file on my NetBSD systems.
Re: How to submit patches?
Le Sun, May 07, 2023 at 06:14:35PM +0200, Martin Husemann a écrit : > On Sun, May 07, 2023 at 04:56:33PM +0200, tlaro...@polynum.com wrote: > > I'm a bit reluctant to put all the platform lists in copy, since this > > is typically generic: it deals with the monitor capacities, updating > > the VESA DMT specs... > > I pointed a few people at your mail, but maybe you could describe the > motivation of the changes a bit more verbosly - at first it all looked > like a lot of churn for no particular reason (but that is probably because > I don't know anything about that part of the source). With NetBSD 10 beta, there was a change in resolution picked-up for the framebuffer compared to 9.3: I have a 16:9 ratio LCD; 9.3 picked-up this ratio and a correct resolution and font for the framebuffer, while 10 beta does not (on the very same hardware). Trying to investigate why this difference, I found nothing obvious. So I started to track back, starting from the end: the monitor. Since I didn't know anything about this stuff, I started to download the published specs by VESA and read the specs. So the first step was to update to the latest VESA DMT and to fix some things that were wrong: there are discrepancies about the Mac monitors "modelines"; some historical modes were missing; Xorg (the source used in NetBSD at least) is not up to date either and was used as a reference for the VESA DMT modes, while with the VESA DMT, de facto and de jure, it should not. Since I can work on that only on very scarce hours, instead of waiting (how long?) to finish all, I prefer to commit a step that is an independant unit by itself and is finished, without breaking anything (it adds modes; it corrects---printing "800x600x60" for a mode is multiplying apples by bananas, since 60 is a frequency so now it appears as "800x600@60Hz" for example; it removes unused things that just complexify things for someone who tries to update the code; etc.) so that at least, _this_, will not have to be done by someone else. Of course, some of the fields added from the VESA DMT would be needed in the future when updating code about EDID. So it is not gratuitous. Next step will be to review the EDID code and I will continue back (praying to not have to deal with drm...) until I find why it doesn't work correctly and understanding the framebuffer stuff. Is this clearer? -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: How to submit patches?
On Sun, May 07, 2023 at 04:56:33PM +0200, tlaro...@polynum.com wrote: > I'm a bit reluctant to put all the platform lists in copy, since this > is typically generic: it deals with the monitor capacities, updating > the VESA DMT specs... I pointed a few people at your mail, but maybe you could describe the motivation of the changes a bit more verbosly - at first it all looked like a lot of churn for no particular reason (but that is probably because I don't know anything about that part of the source). Martin
Re: How to submit patches?
Le Sun, May 07, 2023 at 09:40:56AM -0400, Thor Lancelot Simon a écrit : > On Sat, May 06, 2023 at 12:12:54PM +0200, tlaro...@polynum.com wrote: > > > > How to submit patches without wasting time? (mine included) > > It might be that you get quicker response on one of the mailing lists > for platforms where the patches are particularly useful. It might not, > too - but the set of people with the knowledge to review work in this area > is not so large, and copying the per-port lists might help get their > attention. I'm a bit reluctant to put all the platform lists in copy, since this is typically generic: it deals with the monitor capacities, updating the VESA DMT specs... -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: How to submit patches?
On Sat, May 06, 2023 at 12:12:54PM +0200, tlaro...@polynum.com wrote: > > How to submit patches without wasting time? (mine included) It might be that you get quicker response on one of the mailing lists for platforms where the patches are particularly useful. It might not, too - but the set of people with the knowledge to review work in this area is not so large, and copying the per-port lists might help get their attention. -- Thor Lancelot Simon t...@panix.com "Somehow it works like a joke, but it makes no sense." --Gilbert Gottfried
