Re: More than 16 partitions
Amelia A Lewis wrote: > So, and I recognize that the answer might reasonably be "go read more > code and figure it out yourself," a question for Theo and others if you > have a moment: why couldn't an arch expand past sixteen? It seems, both > from the math calculating struct size (which may be mistaken, in which > case I apologize) and in the comment for MAXMAXPARTITIONS that more > *are* possible. Because there is another reason. Here are the device nodes for two sequentially-numbered disks. brw-r- 1 root operator4, 0 Apr 17 11:50 sd0a brw-r- 1 root operator4, 1 Apr 17 11:50 sd0b brw-r- 1 root operator4, 2 Apr 17 11:50 sd0c brw-r- 1 root operator4, 3 Apr 17 11:50 sd0d brw-r- 1 root operator4, 4 Apr 17 11:50 sd0e brw-r- 1 root operator4, 5 Apr 17 11:50 sd0f brw-r- 1 root operator4, 6 Apr 17 11:50 sd0g brw-r- 1 root operator4, 7 Apr 17 11:50 sd0h brw-r- 1 root operator4, 8 Apr 17 11:50 sd0i brw-r- 1 root operator4, 9 Apr 17 11:50 sd0j brw-r- 1 root operator4, 10 Apr 17 11:50 sd0k brw-r- 1 root operator4, 11 Apr 17 11:50 sd0l brw-r- 1 root operator4, 12 Apr 17 11:50 sd0m brw-r- 1 root operator4, 13 Apr 17 11:50 sd0n brw-r- 1 root operator4, 14 Apr 17 11:50 sd0o brw-r- 1 root operator4, 15 Apr 17 11:50 sd0p brw-r- 1 root operator4, 16 Apr 17 11:50 sd1a brw-r- 1 root operator4, 17 Apr 17 11:50 sd1b brw-r- 1 root operator4, 18 Apr 17 11:50 sd1c brw-r- 1 root operator4, 19 Apr 17 11:50 sd1d brw-r- 1 root operator4, 20 Apr 17 11:50 sd1e brw-r- 1 root operator4, 21 Apr 17 11:50 sd1f brw-r- 1 root operator4, 22 Apr 17 11:50 sd1g brw-r- 1 root operator4, 23 Apr 17 11:50 sd1h brw-r- 1 root operator4, 24 Apr 17 11:50 sd1i brw-r- 1 root operator4, 25 Apr 17 11:50 sd1j brw-r- 1 root operator4, 26 Apr 17 11:50 sd1k brw-r- 1 root operator4, 27 Apr 17 11:50 sd1l brw-r- 1 root operator4, 28 Apr 17 11:50 sd1m brw-r- 1 root operator4, 29 Apr 17 11:50 sd1n brw-r- 1 root operator4, 30 Apr 17 11:50 sd1o brw-r- 1 root operator4, 31 Apr 17 11:50 sd1p Look very carefully at this column ^^
Re: More than 16 partitions
I have a dread sense that I'm going to regret asking questions, but I'm
going to do it anyway, because hey, what the hell, I can always drink
bleach.
On Fri, 24 Apr 2020 19:09:53 -0600, Theo de Raadt wrote:
[snip]
>
> Reality hasn't changed. A sector is still 512 bytes, and
> disklabel has to fit in it.
I doubt that it will improve anything, but some of us (well, at least
me) got intrigued by your answers and the history (I thought that
sixteen was chosen because four bits and it was significant for that
reason, but that was clearly leaping to the same sorts of conclusions
from a different direction than disk size, which was embarrassing). So
I went and had a look at the struct definition.
Some summary for misc-readers who are not Theo or other devs; y'all
skip over me doing base-level analysis, 'kay? Otherwise you'll be rilly
annoyed with me for seeming to talk down to you, but this is for the
other folks who responded on thread without looking at disklabel.h.
/usr/src/sys/disklabel.h, the struct disklabel is the bit in question:
struct disklabel {
u_int32_t d_magic; /* the magic number */
u_int16_t d_type; /* drive type */
u_int16_t d_subtype;/* controller/d_type specific */
char d_typename[16]; /* type name, e.g. "eagle" */
char d_packname[16]; /* pack identifier */
/* disk geometry: */
u_int32_t d_secsize;/* # of bytes per sector */
u_int32_t d_nsectors; /* # of data sectors per track
*/
u_int32_t d_ntracks;/* # of tracks per cylinder */
u_int32_t d_ncylinders; /* # of data cylinders per unit
*/
u_int32_t d_secpercyl; /* # of data sectors per
cylinder */
u_int32_t d_secperunit; /* # of data sectors (low part)
*/
u_char d_uid[8]; /* Unique label identifier. */
/*
* Alternate cylinders include maintenance, replacement,
configuration
* description areas, etc.
*/
u_int32_t d_acylinders; /* # of alt. cylinders per unit
*/
/* hardware characteristics: */
u_int16_t d_bstarth;/* start of useable region
(high part) */
u_int16_t d_bendh; /* size of useable region (high
part) */
u_int32_t d_bstart; /* start of useable region */
u_int32_t d_bend; /* end of useable region */
u_int32_t d_flags; /* generic flags */
#define NDDATA 5
u_int32_t d_drivedata[NDDATA]; /* drive-type specific
information */
u_int16_t d_secperunith;/* # of data sectors (high
part) */
u_int16_t d_version;/* version # (1=48 bit
addressing) */
#define NSPARE 4
u_int32_t d_spare[NSPARE]; /* reserved for future use */
u_int32_t d_magic2; /* the magic number (again) */
u_int16_t d_checksum; /* xor of data incl. partitions
*/
/* filesystem and partition information: */
u_int16_t d_npartitions;/* number of partitions in
following */
u_int32_t d_bbsize; /* size of boot area at sn0,
bytes */
u_int32_t d_sbsize; /* max size of fs superblock,
bytes */
/* at this point, the struct as a whole occupies 160 bytes, in general
metadata
about the disklabel-as-a-whole, not any specific partition. next is
partitions: */
struct partition { /* the partition table */
u_int32_t p_size; /* number of sectors (low part)
*/
u_int32_t p_offset; /* starting sector (low part) */
u_int16_t p_offseth;/* starting sector (high part)
*/
u_int16_t p_sizeh; /* number of sectors (high
part) */
u_int8_t p_fstype; /* filesystem type, see below */
u_int8_t p_fragblock; /* encoded filesystem
frag/block */
u_int16_t p_cpg;/* UFS: FS cylinders per group
*/
} d_partitions[MAXPARTITIONS]; /* actually may be more */
};
struct partition is 16 bytes, times MAXPARTITIONS.
Note that MAXPARTITIONS isn't defined in this header; it's in the
per-arch disklabel.h (/usr/src/arch/*/include/disklabel.h). On the
other hand, at the top of the file is this:
/*
* The absolute maximum number of disk partitions allowed.
* This is the maximum value of MAXPARTITIONS for which 'struct
disklabel'
* is <= DEV_BSIZE bytes long. If MAXPARTITIONS is greater than this,
beware.
*/
#define MAXMAXPARTITIONS22
#if MAXPARTITIONS > MAXMAXPARTITIONS
#warn beware: MAXPARTITIONS bigger than MAXMAXPARTITIONS
#endif
Now, to cut to the chase, /usr/src/arch/*/include/disklabel.h all have
"#define MAXPARTITIONS 16" (whitespace varies, but the number doesn't).
So the standard/universal 16
Re: More than 16 partitions
Theo de Raadt writes: > Reality hasn't changed. A sector is still 512 bytes, and > disklabel has to fit in it. OK. Allan
Re: More than 16 partitions
Strahil Nikolov wrote: > On April 25, 2020 4:09:53 AM GMT+03:00, Theo de Raadt > wrote: > >Allan Streib wrote: > > > >> Theo de Raadt writes: > >> > >> > OpenBSD has apparently become popular amongst people who can't > >think > >> > and connect "real world constraints" and "reality" with "no > >alternative > >> > decision was possible". This is very common amongst people who > >won't > >> > lift their finger. > >> > >> I'm not the one complaining about the 16 partition limit, and I'm not > >> asking for anything to change. I've only said I think it's something > >> that is the way it is because of the design decisions made on the > >basis > >> of "reality" at the time, and which probably didn't contemplate the > >day > >> when everyone would have multi-terabyte hard drives and that people > >> might want more than 16 partitions. I stand corrected on that > >> speculation if I'm wrong. > > > >Reality hasn't changed. A sector is still 512 bytes, and > >disklabel has to fit in it. > > > >You are not LISTENING. > > Does this mean that with a sector of 4096 (modern HDDs/SSDs) and a patch - > we can have larger disklabel ? We access all disks as multiples of 512, no matter what their underlying storage layout is. We align some stuff later, but that does not change the fact "struct disklabel" is precisely 512 bytes longer. Feel free to make your own version of code that works on some machines, but not other machines. Feel free to figure out for yourself how it solves nothing.
Re: More than 16 partitions
On April 25, 2020 4:09:53 AM GMT+03:00, Theo de Raadt wrote: >Allan Streib wrote: > >> Theo de Raadt writes: >> >> > OpenBSD has apparently become popular amongst people who can't >think >> > and connect "real world constraints" and "reality" with "no >alternative >> > decision was possible". This is very common amongst people who >won't >> > lift their finger. >> >> I'm not the one complaining about the 16 partition limit, and I'm not >> asking for anything to change. I've only said I think it's something >> that is the way it is because of the design decisions made on the >basis >> of "reality" at the time, and which probably didn't contemplate the >day >> when everyone would have multi-terabyte hard drives and that people >> might want more than 16 partitions. I stand corrected on that >> speculation if I'm wrong. > >Reality hasn't changed. A sector is still 512 bytes, and >disklabel has to fit in it. > >You are not LISTENING. Does this mean that with a sector of 4096 (modern HDDs/SSDs) and a patch - we can have larger disklabel ? Best Regards, Strahil Nikolov
Re: More than 16 partitions
Allan Streib wrote: > Theo de Raadt writes: > > > OpenBSD has apparently become popular amongst people who can't think > > and connect "real world constraints" and "reality" with "no alternative > > decision was possible". This is very common amongst people who won't > > lift their finger. > > I'm not the one complaining about the 16 partition limit, and I'm not > asking for anything to change. I've only said I think it's something > that is the way it is because of the design decisions made on the basis > of "reality" at the time, and which probably didn't contemplate the day > when everyone would have multi-terabyte hard drives and that people > might want more than 16 partitions. I stand corrected on that > speculation if I'm wrong. Reality hasn't changed. A sector is still 512 bytes, and disklabel has to fit in it. You are not LISTENING.
Re: More than 16 partitions
Theo de Raadt writes: > OpenBSD has apparently become popular amongst people who can't think > and connect "real world constraints" and "reality" with "no alternative > decision was possible". This is very common amongst people who won't > lift their finger. I'm not the one complaining about the 16 partition limit, and I'm not asking for anything to change. I've only said I think it's something that is the way it is because of the design decisions made on the basis of "reality" at the time, and which probably didn't contemplate the day when everyone would have multi-terabyte hard drives and that people might want more than 16 partitions. I stand corrected on that speculation if I'm wrong. Allan
Re: More than 16 partitions
Ingo Schwarze wrote: The limitation to 16 partitions definitely feels painful to me. There is softraid(4). The only discipline that supports a single chunk is crypto. Make a couple of OpenBSD RAID partitions, set them up as crypto, partition those new crypto pseudo-devices, up to 16 partitions each, mkfs, mount, profit. From what I understand, crypto is not that big a performance hit if you have AES on your AMD64 intruction set. I just tried it on a small 16GB usb flash drive. The only issue was getting a clean reboot (rc.local to configure the pseudo-devices succeeds but mount happens too early). John
Re: More than 16 partitions
A little bit of fun, slightly related to some of the discussion: [1] is something that comes into my mind each time i read some of the emails [2] is coming next [1] https://www.youtube.com/watch?v=nlt5Wa13fFU [2] https://www.youtube.com/watch?v=zIV4poUZAQo
Re: Comments in source code
Pretty much this. I am a huge supporter of "useful documentation" but over 90% of what I read either code, techbooks, manuals, the list goes on is written by people who don´t know how to do it properly. OpenBSDs code is clean though as far as I can judge. I read through the whole thing simply for educational purposes and it was a wild ride I have learned a lot doing it and forgot a lot again but it was nice and it´s not often nowadays that you read code and can be quite certain that it is "written to work" and not written to be patched, hotfixed, savaged and whatnot. Read it, understand it, follow @tech and maybe there is a chance to start a discussion about something you understood and don´t agree with. So far I am reading @tech for like 2years, understand a few things and get lost on a lot of things but it´s mostly educational. :) ___ Always exit with 42 to return the answer. ‐‐‐ Original Message ‐‐‐ On Friday, 24. April 2020 07:36, Chris Bennett wrote: > On Thu, Apr 23, 2020 at 05:38:40PM -0400, Aisha Tammy wrote: > > > Thanks a lot for responding, I've had some food so am feeling a lot less > > frustrated :D > > > > > On 4/23/20 12:10 PM, Stuart Henderson wrote: > > > It's often considered better if code is clear enough to stand by itself, > > > keeping comments for the less common cases which can't be figured out > > > from reading the code. And that way you aren't at risk of assuming > > > > But like, not all code is simple enough to understand by just reading it. > > Comments can do more than just explain api, they can help explain > > how the code itself is working. > > I have been reading diff, sdiff diff3 and other string algorithms to > > understand > > how to make it as fast as their GNU counterparts and they are not the > > simplest > > to read, even when knowing the actual string algorithms pretty well. > > If reading the code isn't enough and you see parts you don't understand, > then break those parts. See what happens. Find out why it was done. > You might find out that the code at that spot doesn't even work > correctly. You might figure out a way to fix it or eliminate it. > Perhaps submit a diff. > From your work, you may be able to ask a very specific question. > Specific questions are more likely to be answered. If someone knows the > answer AND also has the time and desire to help. > > You may also find that the old way was great back in older versions of > OpenBSD, but no longer the best way due to changes in the OS. > > > > If you aren't already, you should be looking at commit messages from > > > where the relevant code was touched. That is often where you'll find the > > > explanations you seek. > > > > I have been reading them, Commit messages don't explain algorithms very > > clearly. > > I agree this is a very specific use case but definitely something that > > could be improved. > > Some of the things I've been considering useful (in this specific scenario > > for diff3) > > > > - explanation for merge function, what it does > > - in merge function, explain how empty for loop is used, as this is a > > very big loop > > with a lot of cases > > > > Are you reading commit messages far enough back in time? OpenBSD is a > fork of NetBSD. Maybe you will need to go back much further in time to > find the commit message or discussion that lead up to today. > > I strongly support comments, very strongly. But only when needed. > Explanations are better coming from someone who can discuss with you or > might only be available from you working it out for yourself. > This is a volunteer project. Comments don't get compiled, but they do > take up space, disk space and bandwidth space. > > Have fun, work hard and enjoy yourself. > There are some excellent threads about these topics in the mailing > lists. > > Chris Bennett publickey - flauenroth@protonmail.com - 0xD727BBC1.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: More than 16 partitions
Allan Streib wrote: > Theo de Raadt writes: > > > Allan Streib wrote: > > > >> Seems like one of those numbers that was chosen long ago, when disks > >> had orders of magnitude less storage capacity they have now, and 16 > >> partitions really would have been more than enough. > > > > the word "chosen" makes it seem like such an arbitrary decision. > > No, didn't mean to imply arbitrary or ill-considered, more that > someone(s) decided that to be an adequate number, considering various > requirements and constraints. At the time, that would probably not have > included the common availability of multi-terabyte drives. Obviously I > wasn't there. Incorrect. And wow, you demonstrate an amazing inability to read. All the offsets and sizes have to fit in a 512 byte sector. It wasn't chosen. THERE WAS NO OTHER WAY. OpenBSD has apparently become popular amongst people who can't think and connect "real world constraints" and "reality" with "no alternative decision was possible". This is very common amongst people who won't lift their finger.
Re: More than 16 partitions
Theo de Raadt writes: > Allan Streib wrote: > >> Seems like one of those numbers that was chosen long ago, when disks >> had orders of magnitude less storage capacity they have now, and 16 >> partitions really would have been more than enough. > > the word "chosen" makes it seem like such an arbitrary decision. No, didn't mean to imply arbitrary or ill-considered, more that someone(s) decided that to be an adequate number, considering various requirements and constraints. At the time, that would probably not have included the common availability of multi-terabyte drives. Obviously I wasn't there. Allan
Re: More than 16 partitions
Allan Streib wrote:
> Seems like one of those numbers that was chosen long ago, when disks
> had orders of magnitude less storage capacity they have now, and 16
> partitions really would have been more than enough.
the word "chosen" makes it seem like such an arbitrary decision.
As currently written, the partition table must fit in a single sector.
Read disklabel.h and figure out how this part works:
struct partition { /* the partition table */
u_int32_t p_size; /* number of sectors (low part) */
u_int32_t p_offset; /* starting sector (low part) */
u_int16_t p_offseth;/* starting sector (high part) */
u_int16_t p_sizeh; /* number of sectors (high part) */
u_int8_t p_fstype; /* filesystem type, see below */
u_int8_t p_fragblock; /* encoded filesystem frag/block */
u_int16_t p_cpg;/* UFS: FS cylinders per group */
} d_partitions[MAXPARTITIONS]; /* actually may be more */
...
#define DL_GETDSIZE(d) (((u_int64_t)(d)->d_secperunith << 32) + \
(d)->d_secperunit)
#define DL_SETDSIZE(d, n) do { \
u_int64_t x = (n); \
(d)->d_secperunith = x >> 32; \
(d)->d_secperunit = x; \
} while (0)
#define DL_GETBSTART(d) (((u_int64_t)(d)->d_bstarth << 32) + \
(d)->d_bstart)
#define DL_SETBSTART(d, n) do { \
u_int64_t x = (n); \
(d)->d_bstarth = x >> 32; \
(d)->d_bstart = x; \
} while (0)
etc etc etc
Long time ago, it was chosen that cars should have 4 wheels.
Re: More than 16 partitions
Ingo Schwarze writes: > The limitation to 16 partitions definitely feels painful to me. Well, one pragmatic solution is to add another disk -- 16 more partitions. Not always possible, granted. Seems like one of those numbers that was chosen long ago, when disks had orders of magnitude less storage capacity they have now, and 16 partitions really would have been more than enough. Allan
Re: More than 16 partitions
Lars, Your email didn't contain a diff. Is there a reason for that? I'm wondering whether it is because it is too difficult for you, or maybe it is too difficult for everyone, or maybe you are simply talking out of your ass by trying to assign work to other people because that is your nature? > HAMMER2 could be ported. There is much collaboration between OpenBSD > and DragonflyBSD already (drivers for example). > https://www.dragonflybsd.org/docs/handbook/environmentquickstart/#index3h2 > > On Thu, 2020-04-23 at 16:48 -0400, Eric Furman wrote: > > ZFS cannot be ported to OBSD. It has an unacceptable license. > > If something like it were to be used on OBSD it would have to be > > written from scratch with a BSD license and it has already been > > discussed at length on this list how hard that is. > > Besides it is not really necessary. ZFS is overly complex and not > > needed in most cases. > -- > Lars Schotte > Mudroňova 13 > 92101 Piešťany >
Re: More than 16 partitions
HAMMER2 could be ported. There is much collaboration between OpenBSD and DragonflyBSD already (drivers for example). https://www.dragonflybsd.org/docs/handbook/environmentquickstart/#index3h2 On Thu, 2020-04-23 at 16:48 -0400, Eric Furman wrote: > ZFS cannot be ported to OBSD. It has an unacceptable license. > If something like it were to be used on OBSD it would have to be > written from scratch with a BSD license and it has already been > discussed at length on this list how hard that is. > Besides it is not really necessary. ZFS is overly complex and not > needed in most cases. -- Lars Schotte Mudroňova 13 92101 Piešťany
Re: PPP connection terminated every 5 minutes
> Note the time seqence: > * when ifconfig says time 00:05:00, pings die > * after 20 seconds, a LCP Echo Request comes > * after another 10 seconds, another LCP Echo Request comes > * after another 10 seconds, another LCP Echo Request comes > * after another 10 seconds, a LCP Terminate Request comes > and the connection is established anew. > > This pattern has been repeating since the last midnight. > It looks to me like my ISP is cutting me off every 5 minutes, > and than it takes 50 seconds to realize the connection is down, > which is when it sends the Terminate, > and then the connection is re-established. > > Has anyone seen the same? > Is this a known issue with pppoe connections? > > Searching the archives, I found this: > https://marc.info/?l=openbsd-misc=155053560723855=2 > (but see the entire thread for other details). > > Adam's issue 2 rings a bell, because the drop > happens when I get a new IP6 configuraion request. > I do have the "inet6 eui64" in my setup though. Eh, _now_ I do, and the problem disappeared. It seems that for this ISP at least, I have to accept their IP6 setting: if I don't, my connection gets terminated as described; if I do, everything works as expected. # cat /etc/hostname.pppoe0 # 185.63.96.79 -> 10.11.5.146 # The inet6 settings are necessary, # otherwise we get dropped every 5 minutes inet 0.0.0.0 255.255.255.255 NONE pppoedev vlan0 \ authproto 'pap' authname 'X' authkey 'PASS' up dest 0.0.0.1 inet6 eui64 !/sbin/route add default 0.0.0.1 !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 # ifconfig pppoe0 pppoe0: flags=8851 mtu 1492 index 6 priority 0 llprio 3 dev: vlan0 state: session sid: 0x1 PADI retries: 2 PADR retries: 0 time: 01:28:19 sppp: phase network authproto pap authname "X" groups: pppoe egress status: active inet6 fe80::20d:b9ff:fe56:5efc%pppoe0 -> prefixlen 64 scopeid 0x6 inet 185.63.96.79 --> 10.11.5.146 netmask 0x Sorry for the noise. Jan
Re: More than 16 partitions
Hi Strahil, Strahil Nikolov wrote on Thu, Apr 23, 2020 at 11:16:41PM +0300: > And who the hell needs more than 16 partitions ? Me, and i'm quite sure many do. It's certainly not a good idea to combine any partitions that are separate in a default install because there are good reasons for all the separations. Then, on a development machine, i want separate partitions for src, xenocara, ports and the related obj partitions. Then i need a noperm partition for building releases. And because i sometimes work on free software projects outside OpenBSD, i want a partition for source code control checkouts of other projects. I certainly don't want to to mix /co/ that into /home/ or /usr/src/. At this point, here is the bare minimum i typically have: 01 a / 02 b swap 03 c whole disk 04 d /tmp nodev nosuid 05 e /var nodev nosuid 06 f /usr nodev 07 g /usr/local nodev wxallowed 08 h /usr/src nodev nosuid 09 i /usr/obj nodev nosuid 10 j /usr/xenocaranodev nosuid 11 k /usr/xobjnodev nosuid 12 l /usr/ports nodev nosuid 13 m /usr/ports/pobj nodev nosuid wxallowed 14 n /co nodev nosuid 15 o /co/destdir nodev noexec noperm 16 p /homenodev nosuid So, i'm out of partitions before i even start doing anything even mildly special. I don't even have a single spare partition, even though having that would be quite useful for better keeping track of unused space on the disk that i might keep around for maybe using it later. The limitation to 16 partitions definitely feels painful to me. > Why not we just port ZFS from FreeBSD, or LVM from Linux For starters, neither are free software. Both are encumbered with very restrictive licenses that prevent using them last time i looked (CDDL and GPL). Besides, OpenBSD values code that is small, simple, and easy to audit, so i'm not sure whether these would qualify even if they were free. So trying to port them would be a waste of time. Trying to port HAMMER from DragonFly might be worthwhile, but a huge and difficult project, and i'm not sure it is related to the limitation of the number of partitions. Yours, Ingo
PPP connection terminated every 5 minutes
This is current/amd64 on an APU2.E2. It is connected via pppoe over vlan over em as follows: $ cat /etc/hostname.em0 up $ cat /etc/hostname.vlan848 descr UVTNET vlan 848 vlandev em0 up $ cat /etc/hostname.pppoe0 inet 0.0.0.0 255.255.255.255 NONE pppoedev vlan848 \ authproto 'pap' authname 'X' authkey 'PASS' up dest 0.0.0.1 !/sbin/route add default 0.0.0.1 (The 'X' and 'PASS' are actual bogus values, the ISP filters by the link I am connected to.) $ ifconfig em0 em0: flags=8843 mtu 1500 lladdr 00:0d:b9:56:5e:fc index 1 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) status: active $ ifconfig vlan848 vlan848: flags=8843 mtu 1500 lladdr 00:0d:b9:56:5e:fc description: UVTNET index 8 priority 0 llprio 3 encap: vnetid 848 parent em0 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (1000baseT full-duplex) status: active $ ifconfig pppoe0 pppoe0: flags=8851 mtu 1492 index 7 priority 0 llprio 3 dev: vlan848 state: session sid: 0x1 PADI retries: 5 PADR retries: 0 time: 00:03:17 sppp: phase network authproto pap authname "X" groups: pppoe egress status: active inet6 fe80::20d:b9ff:fe56:5efc%pppoe0 -> prefixlen 64 scopeid 0x7 inet 185.63.96.79 --> 10.11.5.146 netmask 0x The connection works just fine, except it drops every five minutes - I mean after exactly five minutes, for the last ten hours. This is the test I did: (1) in one script, keep pinging out (2) in another script, watch the pppoe up time in a loop: while true ; do date ; ifconfig pppoe0 ; sleep 1; done (3) run a tcpdump during that This is what the pinging looks like: $ ping stary.fit.cvut.cz PING stary.fit.cvut.cz (147.32.232.84): 56 data bytes 64 bytes from 147.32.232.84: icmp_seq=0 ttl=246 time=6.632 ms 64 bytes from 147.32.232.84: icmp_seq=1 ttl=246 time=7.339 ms 64 bytes from 147.32.232.84: icmp_seq=2 ttl=246 time=6.762 ms 64 bytes from 147.32.232.84: icmp_seq=3 ttl=246 time=6.438 ms 64 bytes from 147.32.232.84: icmp_seq=4 ttl=246 time=6.626 ms 64 bytes from 147.32.232.84: icmp_seq=5 ttl=246 time=6.989 ms 64 bytes from 147.32.232.84: icmp_seq=6 ttl=246 time=6.951 ms 64 bytes from 147.32.232.84: icmp_seq=7 ttl=246 time=7.136 ms 64 bytes from 147.32.232.84: icmp_seq=8 ttl=246 time=7.620 ms 64 bytes from 147.32.232.84: icmp_seq=9 ttl=246 time=7.404 ms ^^^ [no reply for about 50 seconds] 64 bytes from 147.32.232.84: icmp_seq=60 ttl=246 time=6.786 ms ^ 64 bytes from 147.32.232.84: icmp_seq=61 ttl=246 time=7.316 ms 64 bytes from 147.32.232.84: icmp_seq=62 ttl=246 time=7.570 ms 64 bytes from 147.32.232.84: icmp_seq=63 ttl=246 time=7.296 ms [getting replies for precisely 300 pings, then repeats] The drop happens exactly when ifconfig pppoe0 says the interface has been up for 5 minues: Fri Apr 24 13:13:28 CEST 2020 pppoe0: flags=8951 mtu 1492 index 7 priority 0 llprio 3 dev: vlan848 state: session sid: 0x1 PADI retries: 5 PADR retries: 0 time: 00:05:00 ^^^ sppp: phase network authproto pap authname "X" groups: pppoe egress status: active inet 185.63.96.79 --> 10.11.5.146 netmask 0x For almost exactly 50 seconds then, the pings are not getting replies. This is what tcpdump says: [pinging away] 13:13:26.840342 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:26.847192 147.32.232.84 > 185.63.96.79: icmp: echo reply 13:13:27.840399 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:27.847448 147.32.232.84 > 185.63.96.79: icmp: echo reply 13:13:28.840398 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:28.847934 147.32.232.84 > 185.63.96.79: icmp: echo reply [ifconfig pppoe0 shows time 00:05:00] [The pings are no longer getting replies] 13:13:29.450416 IPV6CP Configure-Request Id=0xff: IPv6-Interface-Id=427c:7dff:feea:db03 13:13:29.450438 IPV6CP Configure-Ack Id=0xff: IPv6-Interface-Id=427c:7dff:feea:db03 13:13:29.840366 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:29.847671 147.32.232.84 > 185.63.96.79: icmp: echo reply 13:13:30.840381 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:31.840472 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:32.840499 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:33.840449 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:34.840401 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:35.840431 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:36.840437 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:37.840422 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:38.840517 185.63.96.79 > 147.32.232.84: icmp: echo request 13:13:39.840458 185.63.96.79 > 147.32.232.84: icmp: echo request
Re: _types.h: increase size of size_t
On 2020-04-24, Otto Moerbeek wrote: > On Thu, Apr 23, 2020 at 10:45:38PM -0400, Ian Sutton wrote: > >> Following the revalations made by a misc@ poster, I am happy to present >> the following patch which increases the width of size_t from "long" to >> "long long", which is twice the width as before, on all platforms. This >> has the effect of doubling the amount of available memory regardless of >> the physical capacity installed memory hardware. Additionally, it >> enables PAE on all 32 bit platforms without incurring performance costs. > > You must be out of your mind. I assumed it was a mail delayed from 1 April or something :)
Re: Porting Jitsi to OpenBSD
based af will do On 4/24/20 8:36 AM, Daniel Jakots wrote: > On Fri, 24 Apr 2020 08:25:51 -0400, Aisha Tammy > wrote: > >> Hey all, >> I'm hoping to port jitsi and wanted to know if anyone else is already >> working on a port so that I don't do work that might be unnecessary. > > > This kind of email should go on ports@. > Since misc@ has a very low SNR [1] don't assume anyone seriously > working on OpenBSD is actually reading this particular mailing-list. > > [1]: https://en.wikipedia.org/wiki/Signal-to-noise_ratio > > Cheers, > Daniel >
Re: MIdnight Commander won't run
I did a "pkg_add -r pcre" and fixed the issue. mc is now running. Appeared libpcre.so.3.0 was corrupted. Thanks for the support! Jay > > On 2020/04/23 20:04, Jay Hart wrote: >> Here is the output... >> >> Script started on Thu Apr 23 19:37:38 2020 >> ld.so loading: 'mc' >> exe load offset: 0x18c5 >> flags mc = 0x0 >> head mc >> obj mc has mc as head >> examining: 'mc' >> loading: libintl.so.6.0 required by mc >> flags /usr/local/lib/libintl.so.6.0 = 0x0 >> obj /usr/local/lib/libintl.so.6.0 has mc as head >> loading: libc.so.95.1 required by mc >> flags /usr/lib/libc.so.95.1 = 0x20 >> obj /usr/lib/libc.so.95.1 has mc as head >> loading: libssh2.so.9.0 required by mc >> flags /usr/local/lib/libssh2.so.9.0 = 0x0 >> obj /usr/local/lib/libssh2.so.9.0 has mc as head >> loading: libslang.so.16.0 required by mc >> flags /usr/local/lib/libslang.so.16.0 = 0x0 >> obj /usr/local/lib/libslang.so.16.0 has mc as head >> loading: libpthread.so.26.1 required by mc >> flags /usr/lib/libpthread.so.26.1 = 0x8 >> obj /usr/lib/libpthread.so.26.1 has mc as head >> loading: libssl.so.47.6 required by mc >> flags /usr/lib/libssl.so.47.6 = 0x0 >> obj /usr/lib/libssl.so.47.6 has mc as head >> loading: libgmodule-2.0.so.4200.9 required by mc >> flags /usr/local/lib/libgmodule-2.0.so.4200.9 = 0x88 >> obj /usr/local/lib/libgmodule-2.0.so.4200.9 has mc as head >> loading: libcrypto.so.45.5 required by mc >> flags /usr/lib/libcrypto.so.45.5 = 0x0 >> obj /usr/lib/libcrypto.so.45.5 has mc as head >> loading: libm.so.10.1 required by mc >> flags /usr/lib/libm.so.10.1 = 0x0 >> obj /usr/lib/libm.so.10.1 has mc as head >> loading: libz.so.5.0 required by mc >> flags /usr/lib/libz.so.5.0 = 0x0 >> obj /usr/lib/libz.so.5.0 has mc as head >> loading: libcurses.so.14.0 required by mc >> flags /usr/lib/libcurses.so.14.0 = 0x0 >> obj /usr/lib/libcurses.so.14.0 has mc as head >> loading: libutil.so.13.1 required by mc >> flags /usr/lib/libutil.so.13.1 = 0x0 >> obj /usr/lib/libutil.so.13.1 has mc as head >> loading: libglib-2.0.so.4201.2 required by mc >> flags /usr/local/lib/libglib-2.0.so.4201.2 = 0x8 >> obj /usr/local/lib/libglib-2.0.so.4201.2 has mc as head >> loading: libiconv.so.7.0 required by mc >> flags /usr/local/lib/libiconv.so.7.0 = 0x0 >> obj /usr/local/lib/libiconv.so.7.0 has mc as head >> linking dep /usr/lib/libcurses.so.14.0 as child of mc >> linking dep /usr/lib/libm.so.10.1 as child of mc >> linking dep /usr/lib/libutil.so.13.1 as child of mc >> linking dep /usr/lib/libssl.so.47.6 as child of mc >> linking dep /usr/lib/libcrypto.so.45.5 as child of mc >> linking dep /usr/lib/libz.so.5.0 as child of mc >> linking dep /usr/local/lib/libslang.so.16.0 as child of mc >> linking dep /usr/local/lib/libssh2.so.9.0 as child of mc >> objname /usr/local/lib/libgmodule-2.0.so.4200.9 is nodelete >> linking dep /usr/local/lib/libgmodule-2.0.so.4200.9 as child of mc >> linking dep /usr/local/lib/libintl.so.6.0 as child of mc >> linking dep /usr/local/lib/libglib-2.0.so.4201.2 as child of mc >> linking dep /usr/local/lib/libiconv.so.7.0 as child of mc >> linking dep /usr/lib/libpthread.so.26.1 as child of mc >> linking dep /usr/lib/libc.so.95.1 as child of mc >> examining: '/usr/lib/libcurses.so.14.0' >> examining: '/usr/lib/libm.so.10.1' >> examining: '/usr/lib/libutil.so.13.1' >> examining: '/usr/lib/libssl.so.47.6' >> loading: libcrypto.so.45.5 required by /usr/lib/libssl.so.47.6 >> linking dep /usr/lib/libcrypto.so.45.5 as child of /usr/lib/libssl.so.47.6 >> examining: '/usr/lib/libcrypto.so.45.5' >> examining: '/usr/lib/libz.so.5.0' >> examining: '/usr/local/lib/libslang.so.16.0' >> examining: '/usr/local/lib/libssh2.so.9.0' >> loading: libcrypto.so.45.5 required by /usr/local/lib/libssh2.so.9.0 >> loading: libz.so.5.0 required by /usr/local/lib/libssh2.so.9.0 >> loading: libssl.so.47.6 required by /usr/local/lib/libssh2.so.9.0 >> linking dep /usr/lib/libssl.so.47.6 as child of /usr/local/lib/libssh2.so.9.0 >> linking dep /usr/lib/libcrypto.so.45.5 as child of >> /usr/local/lib/libssh2.so.9.0 >> linking dep /usr/lib/libz.so.5.0 as child of /usr/local/lib/libssh2.so.9.0 >> examining: '/usr/local/lib/libgmodule-2.0.so.4200.9' >> loading: libglib-2.0.so.4201.2 required by >> /usr/local/lib/libgmodule-2.0.so.4200.9 >> linking dep /usr/local/lib/libglib-2.0.so.4201.2 as child of >> /usr/local/lib/libgmodule-2.0.so.4200.9 >> examining: '/usr/local/lib/libintl.so.6.0' >> loading: libiconv.so.7.0 required by /usr/local/lib/libintl.so.6.0 >> linking dep /usr/local/lib/libiconv.so.7.0 as child of >> /usr/local/lib/libintl.so.6.0 >> examining: '/usr/local/lib/libglib-2.0.so.4201.2' >> loading: libpthread.so.26.1 required by /usr/local/lib/libglib-2.0.so.4201.2 >> loading: libiconv.so.7.0 required by /usr/local/lib/libglib-2.0.so.4201.2 >> loading: libpcre.so.3.0 required by /usr/local/lib/libglib-2.0.so.4201.2 >> ld.so: mc: can't load library 'libpcre.so.3.0' >> Killed >> >> Script done on Thu Apr 23 19:37:39 2020 >> >> >> >>
Re: OT: Qualcomm MDM
ref: https://marc.info/?l=openbsd-misc=158763262607487=4 indeed i minded the older model IK40 with the written name (instead of the ideogram) on it while the manufacturer's site provides info on the latter only. thank you very much for your time Sir! /tru
Porting Jitsi to OpenBSD
Hey all, I'm hoping to port jitsi and wanted to know if anyone else is already working on a port so that I don't do work that might be unnecessary. Cheers, Aisha
net.inet.ip.ifq missing
Hello, After upgrade to OpenBSD 6.6 I noticed that net.inet.ip.ifq sysctl metrics are no longer there. We used to monitor these values to see that our firewalls are performing properly. Is there any other way to find values of these counters? Quick search through release notes and mailing lists didn't help me find the answer. Thanks! Karlis
Re: Porting Jitsi to OpenBSD
On Fri, 24 Apr 2020 08:25:51 -0400, Aisha Tammy wrote: > Hey all, > I'm hoping to port jitsi and wanted to know if anyone else is already > working on a port so that I don't do work that might be unnecessary. This kind of email should go on ports@. Since misc@ has a very low SNR [1] don't assume anyone seriously working on OpenBSD is actually reading this particular mailing-list. [1]: https://en.wikipedia.org/wiki/Signal-to-noise_ratio Cheers, Daniel
Re: More than 16 partitions
On 2020-04-23, Ian Darwin wrote: > So: I was able to newfs, mount, and use an OpenBSD partition which > disklabel called 'a' and which had no trace of an fdisk partition around it. > > As Allan pointed out, this is not for booting from - none of those > fdisk partitions looks very healthy. biosboot(8) has an MBR boot signature. If the BIOS doesn't check for a valid MBR partition table--some do, some don't--then it should be able to directly run biosboot(8) from sector 0. installboot(8) tries to prevent such a configuration, but it could be tweaked, or you could try to tweak the disklabel and set the type to floppy, because floppies don't have MBR partitions. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: couldn't find audio device
On Fri, Apr 24, 2020 at 09:43:12AM +0200, Damien Thiriet wrote: > Hi misc@, > > > I am trying to make audio records from my web cam but > cannot succeed in doing it. > I read the FAQ, aucat(1), audioctl(1) and sndiod(8) man pages (but I > certainly misunderstood them) and searched the mailing list. > I think they are obvious things I simply don't understand, any help > welcome. > > Looks like my webcam is recognized by the system > > $ dmesg|grep audio > audio0 at azalia1 > uaudio0 at uhub0 port 3 configuration 1 interface 3 "Logitech product 0x0808" > rev 2.00/0.09 addr 2 > uaudio0: class v1, high-speed, sync, channels: 0 play, 1 rec, 2 ctls > audio1 at uaudio0 > > I switched recording on, as advised in the FAQ > $ /usr/bin/doas /usr/sbin/sysctl kern.audio.record=1 > kern.audio.record: 1 -> 1 > > $ aucat -f /dev/audio1 -o test.wav > /dev/audio1: couldn't open audio device > > $ audioctl -f /dev/audio1 > audioctl: /dev/audio1: Device not configured > > I understand I should use sndiod, but doing > # sndiod -f /dev/audio1 > did not help, even after > # rcctl restart sndiod > > What did I miss? My user is member of wheel, I understand he should have > access to /dev/audio1 > You don't need special privileges to use audio, you only need to enable the device in sndiod. To use both of your devices (internal and USB), you could run: rcctl set sndiod flags -f rsnd/0 -f rsnd/1 rcctl restart sndiod At this point you could run: aucat -f snd/1 -o test.wav and /tmp/foo.wav Note that this device is not full-duplex, it is suitable for recording but not for telephony in web browsers. -- Alexandre
Re: couldn't find audio device
On Fri, 24 Apr 2020, Damien Thiriet wrote: > Hi misc@, > > > I am trying to make audio records from my web cam but > cannot succeed in doing it. > I read the FAQ, aucat(1), audioctl(1) and sndiod(8) man pages (but I > certainly misunderstood them) and searched the mailing list. > I think they are obvious things I simply don't understand, any help > welcome. > > Looks like my webcam is recognized by the system > > $ dmesg|grep audio > audio0 at azalia1 > uaudio0 at uhub0 port 3 configuration 1 interface 3 "Logitech product 0x0808" > rev 2.00/0.09 addr 2 > uaudio0: class v1, high-speed, sync, channels: 0 play, 1 rec, 2 ctls > audio1 at uaudio0 > > I switched recording on, as advised in the FAQ > $ /usr/bin/doas /usr/sbin/sysctl kern.audio.record=1 > kern.audio.record: 1 -> 1 > > $ aucat -f /dev/audio1 -o test.wav > /dev/audio1: couldn't open audio device I usually don't record audio on my machine, but I'm not sure you should be using that device directly. aucat(1) says: -f device Use this sndio(7) audio device. Device mode and parameters are determined from audio files. Default is default. And sndio(7) says about device names: From the user's perspective every audio interface, MIDI port, and sndiod(8) service has a name of the form: type[@hostname][,unit]/devnum[.option] maybe something like snd/1 in your case ? (just guessing here, I'm sure there are more knowledgeable people that can help) > > $ audioctl -f /dev/audio1 > audioctl: /dev/audio1: Device not configured > > I understand I should use sndiod, but doing > # sndiod -f /dev/audio1 > did not help, even after > # rcctl restart sndiod > > What did I miss? My user is member of wheel, I understand he should have > access to /dev/audio1 > > > Damien Thiriet > -- Paco Esteban. 0x5818130B8A6DBC03
Re: MIdnight Commander won't run
Does pcretest start, or does it fail in the same way? Can you post output of "objdump -p /usr/local/lib/libpcre.so.3.0" please? I guess "ls -l /usr/local/lib" might give some clues too. On 2020/04/23 20:04, Jay Hart wrote: > Here is the output... > > Script started on Thu Apr 23 19:37:38 2020 > ld.so loading: 'mc' > exe load offset: 0x18c5 > flags mc = 0x0 > head mc > obj mc has mc as head > examining: 'mc' > loading: libintl.so.6.0 required by mc > flags /usr/local/lib/libintl.so.6.0 = 0x0 > obj /usr/local/lib/libintl.so.6.0 has mc as head > loading: libc.so.95.1 required by mc > flags /usr/lib/libc.so.95.1 = 0x20 > obj /usr/lib/libc.so.95.1 has mc as head > loading: libssh2.so.9.0 required by mc > flags /usr/local/lib/libssh2.so.9.0 = 0x0 > obj /usr/local/lib/libssh2.so.9.0 has mc as head > loading: libslang.so.16.0 required by mc > flags /usr/local/lib/libslang.so.16.0 = 0x0 > obj /usr/local/lib/libslang.so.16.0 has mc as head > loading: libpthread.so.26.1 required by mc > flags /usr/lib/libpthread.so.26.1 = 0x8 > obj /usr/lib/libpthread.so.26.1 has mc as head > loading: libssl.so.47.6 required by mc > flags /usr/lib/libssl.so.47.6 = 0x0 > obj /usr/lib/libssl.so.47.6 has mc as head > loading: libgmodule-2.0.so.4200.9 required by mc > flags /usr/local/lib/libgmodule-2.0.so.4200.9 = 0x88 > obj /usr/local/lib/libgmodule-2.0.so.4200.9 has mc as head > loading: libcrypto.so.45.5 required by mc > flags /usr/lib/libcrypto.so.45.5 = 0x0 > obj /usr/lib/libcrypto.so.45.5 has mc as head > loading: libm.so.10.1 required by mc > flags /usr/lib/libm.so.10.1 = 0x0 > obj /usr/lib/libm.so.10.1 has mc as head > loading: libz.so.5.0 required by mc > flags /usr/lib/libz.so.5.0 = 0x0 > obj /usr/lib/libz.so.5.0 has mc as head > loading: libcurses.so.14.0 required by mc > flags /usr/lib/libcurses.so.14.0 = 0x0 > obj /usr/lib/libcurses.so.14.0 has mc as head > loading: libutil.so.13.1 required by mc > flags /usr/lib/libutil.so.13.1 = 0x0 > obj /usr/lib/libutil.so.13.1 has mc as head > loading: libglib-2.0.so.4201.2 required by mc > flags /usr/local/lib/libglib-2.0.so.4201.2 = 0x8 > obj /usr/local/lib/libglib-2.0.so.4201.2 has mc as head > loading: libiconv.so.7.0 required by mc > flags /usr/local/lib/libiconv.so.7.0 = 0x0 > obj /usr/local/lib/libiconv.so.7.0 has mc as head > linking dep /usr/lib/libcurses.so.14.0 as child of mc > linking dep /usr/lib/libm.so.10.1 as child of mc > linking dep /usr/lib/libutil.so.13.1 as child of mc > linking dep /usr/lib/libssl.so.47.6 as child of mc > linking dep /usr/lib/libcrypto.so.45.5 as child of mc > linking dep /usr/lib/libz.so.5.0 as child of mc > linking dep /usr/local/lib/libslang.so.16.0 as child of mc > linking dep /usr/local/lib/libssh2.so.9.0 as child of mc > objname /usr/local/lib/libgmodule-2.0.so.4200.9 is nodelete > linking dep /usr/local/lib/libgmodule-2.0.so.4200.9 as child of mc > linking dep /usr/local/lib/libintl.so.6.0 as child of mc > linking dep /usr/local/lib/libglib-2.0.so.4201.2 as child of mc > linking dep /usr/local/lib/libiconv.so.7.0 as child of mc > linking dep /usr/lib/libpthread.so.26.1 as child of mc > linking dep /usr/lib/libc.so.95.1 as child of mc > examining: '/usr/lib/libcurses.so.14.0' > examining: '/usr/lib/libm.so.10.1' > examining: '/usr/lib/libutil.so.13.1' > examining: '/usr/lib/libssl.so.47.6' > loading: libcrypto.so.45.5 required by /usr/lib/libssl.so.47.6 > linking dep /usr/lib/libcrypto.so.45.5 as child of /usr/lib/libssl.so.47.6 > examining: '/usr/lib/libcrypto.so.45.5' > examining: '/usr/lib/libz.so.5.0' > examining: '/usr/local/lib/libslang.so.16.0' > examining: '/usr/local/lib/libssh2.so.9.0' > loading: libcrypto.so.45.5 required by /usr/local/lib/libssh2.so.9.0 > loading: libz.so.5.0 required by /usr/local/lib/libssh2.so.9.0 > loading: libssl.so.47.6 required by /usr/local/lib/libssh2.so.9.0 > linking dep /usr/lib/libssl.so.47.6 as child of /usr/local/lib/libssh2.so.9.0 > linking dep /usr/lib/libcrypto.so.45.5 as child of > /usr/local/lib/libssh2.so.9.0 > linking dep /usr/lib/libz.so.5.0 as child of /usr/local/lib/libssh2.so.9.0 > examining: '/usr/local/lib/libgmodule-2.0.so.4200.9' > loading: libglib-2.0.so.4201.2 required by > /usr/local/lib/libgmodule-2.0.so.4200.9 > linking dep /usr/local/lib/libglib-2.0.so.4201.2 as child of > /usr/local/lib/libgmodule-2.0.so.4200.9 > examining: '/usr/local/lib/libintl.so.6.0' > loading: libiconv.so.7.0 required by /usr/local/lib/libintl.so.6.0 > linking dep /usr/local/lib/libiconv.so.7.0 as child of > /usr/local/lib/libintl.so.6.0 > examining: '/usr/local/lib/libglib-2.0.so.4201.2' > loading: libpthread.so.26.1 required by /usr/local/lib/libglib-2.0.so.4201.2 > loading: libiconv.so.7.0 required by /usr/local/lib/libglib-2.0.so.4201.2 > loading: libpcre.so.3.0 required by /usr/local/lib/libglib-2.0.so.4201.2 > ld.so: mc: can't load library 'libpcre.so.3.0' > Killed > > Script done on Thu Apr 23 19:37:39 2020 > > > > > Stuart, > > > > I'm working on capturing the
Re: timegm()
Hi Todd, Todd C. Miller wrote on Wed, Apr 22, 2020 at 09:21:28PM -0600: > On Thu, 23 Apr 2020 04:21:42 +0200, Ingo Schwarze wrote: >> Calling timelocal(3) deprecated makes sense to me because it is >> nothing but a trivial wrapper around mktime(3), and the latter >> is standardized, while timelocal(3) is not. >> >> But i don't quite see why timegm(3) should be marked as deprecated: >> sure it was never standardized, but i don't see a better portable >> way to achieve the same. >> >> Consequently, i suggest dropping millert's deprecation notice >> from timegm(3) and instead adding the missing STANDARDS and >> HISTORY sections. > That's fine with me. Those interfaces appeared in SunOS 4.0 according > to tzcode (which is where we got them from). They did *not* originate > in NetBSD. I've verified that they were present in SunOS 4.1.3U1, > though that code appears to be derived from tzcode too. > > I would suggest that the HISTORY section be updated accordingly if > you feel the need to document their origin. > > If you look at the 4.4BSD ctime.c you'll see that Keith actually > removed timegm() after updating it from tzcode. > > D 5.16 89/03/16 20:34:41 bostic 22 21 > remove offtime, timegm, timeoff > > D 5.15 89/03/12 16:32:29 bostic 21 20 > latest Olson/Harris time package Thanks for doing that research and also for checking the rest of the patch. I tweaked the patch according to your findings and committed it. > The reason they were marked as deprecated is that tzcode has a > comment that "These functions may well disappear in future releases > of the time conversion package". However, that hasn't happened in > at least 30 years so it seems likely that they are here to stay... Sorry for calling you a muppet even though all you actually did was quoting the opinion muppets, a single time about two decades ago. ;-D > Note that we also provide timeoff() but don't document it. I have no strong opinion whether we should document it. Maybe not? I never felt a need to use it, and it isn't standardized. Are you suggesting that maybe we should? I wouldn't oppose that either. Yours, Ingo
Re: _types.h: increase size of size_t
On Thu, Apr 23, 2020 at 10:45:38PM -0400, Ian Sutton wrote: > Following the revalations made by a misc@ poster, I am happy to present > the following patch which increases the width of size_t from "long" to > "long long", which is twice the width as before, on all platforms. This > has the effect of doubling the amount of available memory regardless of > the physical capacity installed memory hardware. Additionally, it > enables PAE on all 32 bit platforms without incurring performance costs. You must be out of your mind. -Otto > > Index: arch/alpha/include/_types.h > === > RCS file: /cvs/src/sys/arch/alpha/include/_types.h,v > retrieving revision 1.24 > diff -u -p -r1.24 _types.h > --- arch/alpha/include/_types.h 5 Mar 2018 01:15:24 - 1.24 > +++ arch/alpha/include/_types.h 24 Apr 2020 02:26:13 - > @@ -120,7 +120,7 @@ typedef unsigned long __psize_t; > typedef double __double_t; > typedef float__float_t; > typedef long __ptrdiff_t; > -typedef unsigned long __size_t; > +typedef unsigned long long__size_t; > typedef long__ssize_t; > #if defined(__GNUC__) && __GNUC__ >= 3 > typedef __builtin_va_list __va_list; > Index: arch/amd64/include/_types.h > === > RCS file: /cvs/src/sys/arch/amd64/include/_types.h,v > retrieving revision 1.17 > diff -u -p -r1.17 _types.h > --- arch/amd64/include/_types.h 5 Mar 2018 01:15:25 - 1.17 > +++ arch/amd64/include/_types.h 24 Apr 2020 02:26:13 - > @@ -120,7 +120,7 @@ typedef unsigned long __psize_t; > typedef double __double_t; > typedef float __float_t; > typedef long __ptrdiff_t; > -typedef unsigned long __size_t; > +typedef unsigned long long__size_t; > typedef long__ssize_t; > #if defined(__GNUC__) && __GNUC__ >= 3 > typedef __builtin_va_list __va_list; > Index: arch/arm/include/_types.h > === > RCS file: /cvs/src/sys/arch/arm/include/_types.h,v > retrieving revision 1.19 > diff -u -p -r1.19 _types.h > --- arch/arm/include/_types.h 5 Mar 2018 01:15:25 - 1.19 > +++ arch/arm/include/_types.h 24 Apr 2020 02:26:13 - > @@ -120,7 +120,7 @@ typedef unsigned long __psize_t; > typedef double __double_t; > typedef float__float_t; > typedef long __ptrdiff_t; > -typedef unsigned long __size_t; > +typedef unsigned long long__size_t; > typedef long__ssize_t; > #if defined(__GNUC__) && __GNUC__ >= 3 > typedef __builtin_va_list __va_list; > Index: arch/arm64/include/_types.h > === > RCS file: /cvs/src/sys/arch/arm64/include/_types.h,v > retrieving revision 1.4 > diff -u -p -r1.4 _types.h > --- arch/arm64/include/_types.h 5 Mar 2018 01:15:25 - 1.4 > +++ arch/arm64/include/_types.h 24 Apr 2020 02:26:13 - > @@ -121,7 +121,7 @@ typedef unsigned long __psize_t; > typedef double __double_t; > typedef float __float_t; > typedef long__ptrdiff_t; > -typedef unsigned long __size_t; > +typedef unsigned long long__size_t; > typedef long__ssize_t; > #if defined(__GNUC__) && __GNUC__ >= 3 > typedef __builtin_va_list __va_list; > Index: arch/hppa/include/_types.h > === > RCS file: /cvs/src/sys/arch/hppa/include/_types.h,v > retrieving revision 1.26 > diff -u -p -r1.26 _types.h > --- arch/hppa/include/_types.h5 Mar 2018 01:15:25 - 1.26 > +++ arch/hppa/include/_types.h24 Apr 2020 02:26:13 - > @@ -124,7 +124,7 @@ typedef unsigned long __psize_t; > typedef double __double_t; > typedef float__float_t; > typedef long __ptrdiff_t; > -typedef unsigned long __size_t; > +typedef unsigned long long__size_t; > typedef long__ssize_t; > #if defined(__GNUC__) && __GNUC__ >= 3 > typedef __builtin_va_list __va_list; > Index: arch/i386/include/_types.h > === > RCS file: /cvs/src/sys/arch/i386/include/_types.h,v > retrieving revision 1.23 > diff -u -p -r1.23 _types.h > --- arch/i386/include/_types.h5 Mar 2018 01:15:25 - 1.23 > +++ arch/i386/include/_types.h24 Apr 2020
Re: _types.h: increase size of size_t
On Fri, Apr 24, 2020 at 4:47 AM Ian Sutton wrote: > > Following the revalations made by a misc@ poster, I am happy to present > the following patch which increases the width of size_t from "long" to > "long long", which is twice the width as before, on all platforms. This > has the effect of doubling the amount of available memory regardless of > the physical capacity installed memory hardware. Additionally, it > enables PAE on all 32 bit platforms without incurring performance costs. This may go against a direct recommendation in the C standard for some or all of these platforms. "The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary." Presumably the unnamed misc@ poster was unsafely mixing pointers and integer types.
Re: rc daemon_timeout
Le jeu. 23 avr. 2020 à 16:41, Antoine Jacoutot a
écrit :
> On Thu, Apr 23, 2020 at 02:34:20PM +0200, Thomas de Grivel wrote:
> > I tried changing the following line in /etc/rc.d/rc.subr but the
> > actual timeout remains 30 sec (from 'time').
> > > [ -z "${daemon_timeout}" ] && daemon_timeout=600
>
> rm /var/run/rc.d/my_daemon
>
Thanks Antoine I'll try that.
Meanwhile I realized my script does not daemonize so it worked to just set
rc_bg=YES
couldn't find audio device
Hi misc@, I am trying to make audio records from my web cam but cannot succeed in doing it. I read the FAQ, aucat(1), audioctl(1) and sndiod(8) man pages (but I certainly misunderstood them) and searched the mailing list. I think they are obvious things I simply don't understand, any help welcome. Looks like my webcam is recognized by the system $ dmesg|grep audio audio0 at azalia1 uaudio0 at uhub0 port 3 configuration 1 interface 3 "Logitech product 0x0808" rev 2.00/0.09 addr 2 uaudio0: class v1, high-speed, sync, channels: 0 play, 1 rec, 2 ctls audio1 at uaudio0 I switched recording on, as advised in the FAQ $ /usr/bin/doas /usr/sbin/sysctl kern.audio.record=1 kern.audio.record: 1 -> 1 $ aucat -f /dev/audio1 -o test.wav /dev/audio1: couldn't open audio device $ audioctl -f /dev/audio1 audioctl: /dev/audio1: Device not configured I understand I should use sndiod, but doing # sndiod -f /dev/audio1 did not help, even after # rcctl restart sndiod What did I miss? My user is member of wheel, I understand he should have access to /dev/audio1 Damien Thiriet
