Long time no see! Also, year 2100 issue...
Hi loyal Creamy fans, Sorry if you've missed me for the last year or so, but I'm back, (from the future), now. So, anyway, the latest commit to msdosfs_conv.c causes a small problem in the year 2100. The DOS end of time is 12/31/2107. Now that we support 2038, msdosfs_conv.c was patched to set timestamps past this date to 1/1/1980. However, the code to process leap years continues to use a simple: year 0x03 ? 365 : 366 which is broken for the year 2100. Every year is a normal year, except every fourth year which is a leap year, except every four-hundredth year which is a normal year. The upshot of this is that the year 2000 WAS a leap year, even though centinary years normally are NOT. So, the simple test above works for all years between 1970 and 2038. 2100 is the first year that fails this simple test. The easiest way to fix it is to change the dos end of time to 12/31/2099. To further complicate the algorithm for all conversions seems a bit excessive when hopefully nobody will be using FAT so far in to the future. (At least, whilst I was in the year 2100, I didn't notice anybody using it). More bugs to follow... Creamy! 3
fun with smtpd, (two bugs)
Hi, So, now that smtpd is due to replace sendmail as the default mailer, it would be nice if it actually worked correctly... First of all, the man page for smtpd.conf states that directives 'from source' and 'senders' take the name of a table as an argument, which is not true. For example: Your email address of choice is creamy@creamylan, and you want to relay mail addressed to example.com via an SMTP server at smtp.creamylan.lan. From reading the man pages, you would be forgiven for thinking that the following will work: table creamy db:/etc/mail/creamy.db table secrets db:/etc/mail/secrets.db accept sender creamy for domain example.com relay via smtps+auth://foo...@smtp.creamylan.lan auth secrets where the secrets file contains: foobar creamyusername:creamypassword and the creamy file contains: creamy@creamylan but it doesn't work. Infact, it works perfectly when you do: table secrets db:/etc/mail/secrets.db accept sender creamy@creamylan for domain example.com relay via smtps+auth://foo...@smtp.creamylan.lan auth secrets note that the 'for domain' directive is explained correctly in the man page. OK, so that's not too bad, but it's not the only bug in smtpd. If you've impatient and issue a load of: # smtpctl reschedule all every 10 seconds when it's failing because of an unreliable server at the other end, or because you made a typo in your password and don't notice it, believing that it's a problem with the server, then after about 5 minutes, you'll get a warning back telling you that the message remained undelivered for 4 hours. Looks to me like warnings are being triggered by the delay before next attempt field rather than (current time - time of sending), but I haven't had chance to have a closer look yet. -- Creamy! 3
Re: fun with smtpd, (two bugs)
On Sat, May 10, 2014 at 06:48:18PM +0200, Denis Fondras wrote: Le 10/05/2014 17:54, Creamy a ?crit : table creamy db:/etc/mail/creamy.db table secrets db:/etc/mail/secrets.db accept sender creamy for domain example.com relay via smtps+auth://foo...@smtp.creamylan.lan auth secrets Shouldn't it be : accept sender creamy for domain example.com ... Examples from the man page: sender [!] senders if specified, the rule will only be matched if the sender email address is found in the table senders. for [!] domain domain [alias aliases] this rule applies to mail destined for the specified domain. for [!] domain domains [alias aliases] this rule applies to mail destined to domains which are part of the table domains So it strongly implies that sender always takes the name of a table as an argument. I've tested this, and yes, as you suggest it accepts either the name of a table inclosed in angle brackets or a literal string without. So the manual page is wrong, or at least misleading, because the syntax of the examples differs between from, sender, and for, so it's not clear whether the angle brackets are intended to be literally included, or whether they are just markup in the man page to indicate, 'name of table'. -- Creamy! 3
Re: fun with smtpd, (two bugs)
On Sat, May 10, 2014 at 10:39:22PM +0200, Frank Brodbeck wrote: On Sat, May 10, 2014 at 07:03:14PM +0100, Creamy wrote: So the manual page is wrong, or at least misleading, because the syntax of the examples differs between from, sender, and for, so it's not clear whether the angle brackets are intended to be literally included, or whether they are just markup in the man page to indicate, 'name of table'. And it's going to fix itself? Don't think so... Index: smtpd.conf.5 === RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v retrieving revision 1.117 diff -u -r1.117 smtpd.conf.5 --- smtpd.conf.5 16 Feb 2014 21:59:34 - 1.117 +++ smtpd.conf.5 10 May 2014 20:40:02 - @@ -109,7 +109,7 @@ .Ic from .Op Ic \! .Ic source -.Ic table +.Aq Ar table .Xc The rule matches if the connection is made from a client whose address is declared in the table @@ -121,7 +121,7 @@ .It Xo .Ic sender .Op Ic \! -.Ic senders +.Aq Ar senders .Xc If specified, the rule will only be matched if the sender email address is found in the table @@ -253,7 +253,7 @@ .It Xo .Ic recipient .Op Ic \! -.Ar recipients +.Aq Ar recipients .Xc If specified, the rule will only be matched if the recipient email address is found in the table @@ -307,7 +307,7 @@ .Ic relay .Op Ic backup Op Ar mx .Op Ic as Ar address -.Op Ic source Ar source +.Op Ic source Aq Ar source .Bk -words .Op Ic hostname Ar name .Op Ic hostnames Ar names @@ -592,7 +592,7 @@ .Op Ic port Ar port .Op Ic tls | tls-require | tls-require verify | smtps | secure .Op Ic pki Ar pkiname -.Op Ic auth | auth-optional | auth Ar authtable | Ic auth-optional Ar authtable +.Op Ic auth | auth-optional | auth Aq Ar authtable | Ic auth-optional Aq Ar authtable Shouldn't that be: +.Op Ic auth | auth-optional | auth Aq Ar authtable Aq | Ic auth-optional Ar authtable ??? Looks like it fixed itself incorrectly :-))) .Op Ic tag Ar tag .Op Ic hostname Ar hostname .Op Ic hostnames Ar names -- Frank Brodbeck f...@guug.de -- Creamy! 3
dhclient bug when joining new wireless lan
Hello again! OK, this time it's a bug, (or is it a feature?), in dhclient. Imagine that you have two separate wireless networks, which operate independently using the same private address spaces and offer leases based on the same algorithm computed from the MAC address of the client. For example: Network 1 - SSID foo, AP IP 192.168.64.1 netmask 255.255.255.0 Network 2 - SSID bar, AP IP 192.168.64.1 netmask 255.255.255.0 But these are NOT connected in any way. They are two completely different networks. E.G. 192.168.64.20, (by way of example), on foo, is a different machine to 192.168.64.20 on bar. Maybe one is your office network and one is a home network. Now, imagine that you have another machine, (probably a laptop), which connects to either one, but never both at the same time. This machine is assigned an IP by DHCP when it joins either network. The DHCP server assigns IPs based pseudo randomly based on MAC address. If both networks use identical algorithms to calculate this IP, then the laptop will be assigned the same IP regardless of the network it joins. Imagine that it's assigned 192.168.64.10. This causes problems with dhclient, when you switch between networks whilst a lease is still valid on the first one. It works, but if you pass the -L option to dhclient, it doesn't produce the normal output, presumably because it believes that it's continuing with an active lease. This causes problems with scripts. A script such as this: #!/bin/sh ifconfig if0 nwid foo wpakey bar sleep 3 dhclient -L /output cat /output fails with cat: /test: No such file or directory. dhclient needs to recognise that it is not just continuing with an active lease, even though the new lease has the same parameters it has come from a different dhcp server. -- Creamy! 3
Re: dhclient bug when joining new wireless lan
On Sun, May 11, 2014 at 06:03:24AM -0400, Kenneth Westerback wrote: On 11 May 2014 05:26, Creamy cre...@dishplanning.com wrote: Hello again! OK, this time it's a bug, (or is it a feature?), in dhclient. Imagine that you have two separate wireless networks, which operate independently using the same private address spaces and offer leases based on the same algorithm computed from the MAC address of the client. For example: Network 1 - SSID foo, AP IP 192.168.64.1 netmask 255.255.255.0 Network 2 - SSID bar, AP IP 192.168.64.1 netmask 255.255.255.0 But these are NOT connected in any way. They are two completely different networks. E.G. 192.168.64.20, (by way of example), on foo, is a different machine to 192.168.64.20 on bar. Maybe one is your office network and one is a home network. Now, imagine that you have another machine, (probably a laptop), which connects to either one, but never both at the same time. This machine is assigned an IP by DHCP when it joins either network. The DHCP server assigns IPs based pseudo randomly based on MAC address. If both networks use identical algorithms to calculate this IP, then the laptop will be assigned the same IP regardless of the network it joins. Imagine that it's assigned 192.168.64.10. This causes problems with dhclient, when you switch between networks whilst a lease is still valid on the first one. It works, Whew. At least it works. Yes, it works quite well actually, the behavior I've noticed might not even matter. but if you pass the -L option to dhclient, it doesn't produce the At last! Somebody using -L! Well, I use it to monitor exactly what's coming back from the DHCP server when it's one that I don't trust :-). Call me paranoid, but since the DHCP protocol supports much more than just assigning an IP address lease, I like to see what the remote end is trying to do, before it changes an obscure aspect of my networking configuration. (Although thankfully the current code doesn't implement the majority of stupid things listed in tables.c). normal output, presumably because it believes that it's continuing with an active lease. Possibly, since I believe you are saying the dhcp servers have the same IP or provide the same server id. dhclient currently has no way to detect that the nwid and only the nwid has changed. Well, it could notice differences in, for example, the vendor-encapsulated-options string, which it currently ignores. This causes problems with scripts. A script such as this: #!/bin/sh ifconfig if0 nwid foo wpakey bar sleep 3 dhclient -L /output cat /output fails with cat: /test: No such file or directory. This seems implausible. Why would cat complain about /test here? Assuming that's a typo, It was, sorry. cat: /output: No such file or directory. can you provide some more details on what version of OpenBSD you have installed? Well I'm testing this on a 5.5-release box, but saw the same behavior with 5.4-release. Some -L changes went in recently. There is also a race in your script since dhclient will not be guaranteed to have finished with /output before your cat runs. I realise that, but it's always used interactively by me, so it's not critical in my case. dhclient needs to recognise that it is not just continuing with an active lease, even though the new lease has the same parameters it has come from a different dhcp server. Different how? Does it at least have a different MAC? Different MAC, with one server returning a random string in vendor-encapsulated-options, and the other not returning anything. My worry is that this might have side effects that I haven't noticed. If the second server is evil in nature, can it take advantage in any way that the client thinks that it's just maintaining an existing lease from another server? If not, it doesn't matter. -- Creamy! 3 pgpAr3xM17IAm.pgp Description: PGP signature
Re: dhclient bug when joining new wireless lan
On Sun, May 11, 2014 at 06:31:23AM -0400, Kenneth Westerback wrote: On 11 May 2014 06:03, Kenneth Westerback kwesterb...@gmail.com wrote: On 11 May 2014 05:26, Creamy cre...@dishplanning.com wrote: Hello again! OK, this time it's a bug, (or is it a feature?), in dhclient. Imagine that you have two separate wireless networks, which operate independently using the same private address spaces and offer leases based on the same algorithm computed from the MAC address of the client. For example: Network 1 - SSID foo, AP IP 192.168.64.1 netmask 255.255.255.0 Network 2 - SSID bar, AP IP 192.168.64.1 netmask 255.255.255.0 But these are NOT connected in any way. They are two completely different networks. E.G. 192.168.64.20, (by way of example), on foo, is a different machine to 192.168.64.20 on bar. Maybe one is your office network and one is a home network. Now, imagine that you have another machine, (probably a laptop), which connects to either one, but never both at the same time. This machine is assigned an IP by DHCP when it joins either network. The DHCP server assigns IPs based pseudo randomly based on MAC address. If both networks use identical algorithms to calculate this IP, then the laptop will be assigned the same IP regardless of the network it joins. Imagine that it's assigned 192.168.64.10. This causes problems with dhclient, when you switch between networks whilst a lease is still valid on the first one. It works, Whew. At least it works. but if you pass the -L option to dhclient, it doesn't produce the At last! Somebody using -L! normal output, presumably because it believes that it's continuing with an active lease. Possibly, since I believe you are saying the dhcp servers have the same IP or provide the same server id. dhclient currently has no way to detect that the nwid and only the nwid has changed. Possibly, but it turns out not. Even if the lease is determined to be identical, the bind_lease() function will re-write the -L file by calling rewrite_option_db(). But even this is inapplicable in the situation you describe since your script starts a new dhclient, and it will not have a lease bound to the interface and will never conclude that it is responsible for the address in place. Thus it will do the full monty of deleting existing addresses and binding the lease it gets. Agreed. This causes problems with scripts. A script such as this: #!/bin/sh ifconfig if0 nwid foo wpakey bar sleep 3 dhclient -L /output cat /output fails with cat: /test: No such file or directory. This seems implausible. Why would cat complain about /test here? Assuming that's a typo, can you provide some more details on what version of OpenBSD you have installed? Some -L changes went in recently. There is also a race in your script since dhclient will not be guaranteed to have finished with /output before your cat runs. There is also a conceivable race between the old and the new dhclient. One trying to truncate the file to indicate it has not configured an address and one trying to repopulate the file with new lease info. I haven't seen that in my testing. Are you saying the behaviour you report is consistent? Or occasional? Initially I only saw it in the situation I described above, where it occurs almost all the time. But after testing, it happens occasionally if I just start a new dhclient on the same interface connected to the same wlan. So, most likely it is a race, possibly a timing difference in the response from the servers making one situation worse than the other with my setup. I didn't realise at first that a new dhclient instance always polls the DHCP server afresh, I thought it would use existing leases that had been allocated and not expired. What happens if the dhcp server doesn't respond? Do we re-use an old but not expired lease? -- Creamy! 3
Re: dhclient bug when joining new wireless lan
On Sun, May 11, 2014 at 06:52:51AM -0400, Kenneth Westerback wrote: On 11 May 2014 06:38, Creamy cre...@dishplanning.com wrote: On Sun, May 11, 2014 at 06:03:24AM -0400, Kenneth Westerback wrote: On 11 May 2014 05:26, Creamy cre...@dishplanning.com wrote: Hello again! OK, this time it's a bug, (or is it a feature?), in dhclient. Imagine that you have two separate wireless networks, which operate independently using the same private address spaces and offer leases based on the same algorithm computed from the MAC address of the client. For example: Network 1 - SSID foo, AP IP 192.168.64.1 netmask 255.255.255.0 Network 2 - SSID bar, AP IP 192.168.64.1 netmask 255.255.255.0 But these are NOT connected in any way. They are two completely different networks. E.G. 192.168.64.20, (by way of example), on foo, is a different machine to 192.168.64.20 on bar. Maybe one is your office network and one is a home network. Now, imagine that you have another machine, (probably a laptop), which connects to either one, but never both at the same time. This machine is assigned an IP by DHCP when it joins either network. The DHCP server assigns IPs based pseudo randomly based on MAC address. If both networks use identical algorithms to calculate this IP, then the laptop will be assigned the same IP regardless of the network it joins. Imagine that it's assigned 192.168.64.10. This causes problems with dhclient, when you switch between networks whilst a lease is still valid on the first one. It works, Whew. At least it works. Yes, it works quite well actually, the behavior I've noticed might not even matter. but if you pass the -L option to dhclient, it doesn't produce the At last! Somebody using -L! Well, I use it to monitor exactly what's coming back from the DHCP server when it's one that I don't trust :-). Call me paranoid, but since the DHCP protocol supports much more than just assigning an IP address lease, I like to see what the remote end is trying to do, before it changes an obscure aspect of my networking configuration. (Although thankfully the current code doesn't implement the majority of stupid things listed in tables.c). normal output, presumably because it believes that it's continuing with an active lease. Possibly, since I believe you are saying the dhcp servers have the same IP or provide the same server id. dhclient currently has no way to detect that the nwid and only the nwid has changed. Well, it could notice differences in, for example, the vendor-encapsulated-options string, which it currently ignores. It already compares the contents of all options. Of which vendor-encapsulated-options is one, i.e. option 43. Any difference in length or detected by memcmp() would mean the leases are deemed not identical, compare_lease() fails and normal processing of a new lease proceeds. Oh, OK, excellent... So the situation I was worrying about doesn't exist. Sorry for the noise. I had assumed that the lack of output from -L indicated that it was recycling an old lease, but as you point out this isn't the case. This causes problems with scripts. A script such as this: #!/bin/sh ifconfig if0 nwid foo wpakey bar sleep 3 dhclient -L /output cat /output fails with cat: /test: No such file or directory. This seems implausible. Why would cat complain about /test here? Assuming that's a typo, It was, sorry. cat: /output: No such file or directory. can you provide some more details on what version of OpenBSD you have installed? Well I'm testing this on a 5.5-release box, but saw the same behavior with 5.4-release. If you want to test the latest changes you need to be trying -current snapshots. Sorry, I'm running with some custom changes to make some other hardware work on this box, and at the moment I haven't had time to update them for -current. Some -L changes went in recently. There is also a race in your script since dhclient will not be guaranteed to have finished with /output before your cat runs. I realise that, but it's always used interactively by me, so it's not critical in my case. dhclient needs to recognise that it is not just continuing with an active lease, even though the new lease has the same parameters it has come from a different dhcp server. Different how? Does it at least have a different MAC? Different MAC, with one server returning a random string in vendor-encapsulated-options, and the other not returning anything. Then the leases are as different as they can be. You can validate this by tweaking the bound to ... message issued by bind_lease() when it has decided the leases are identical and the interface, routing table and resolv.conf do not need to be updated. OK. My worry is that this might have side effects
Re: dhclient bug when joining new wireless lan
Sorry, I'm running with some custom changes to make some other hardware work on this box, and at the moment I haven't had time to update them for -current. Mmm what hardware? It may be that it's supported in -current already and I'm running with some changes to wscons to support my 122-key mainframe style keyboard in a useful way. That is to say supporting VT switching and other 'commands' on dedicated keys. Also, my repeat key patch from last year never made it in to mainline to I've got that here as well. Around November last year, the framebuffer code was changed which made the console impossibly slow for me on three boxes, so I've made some local changes to repair that regression. Also, regarding wifi, I am experimenting with three wifi cards, one of which gained support in mainline between 5.4-release and 5.5-release, onr of the others is long supported, the other not supported or working very well at all at the moment, despite being almost identical to another that I have. When using OpenBSD with a wifi card in host AP mode, it's obvious that something is wrong with the rate control code, because it never seems to go about 2 mbit. So, I've got some changes to the rate control code and one device driver in at the same time. With all this going on, it's not trivial to follow -current on these boxes at the moment. But I will see what I can do and maybe port some of my bits forward. It's really a shame that the repeat key and other wscons changes are not of interest, because I'm sure there are other people that could use them. Unfortunately after my modified repeat key patch was rejected, (silently), I reverted to a simpler version that breaks other stuff, because it suited me better for my own boxes and was easier to port forward every six months. Oh, and I fixed a couple of time related bugs in my tree as well. anyway for getting support inside OpenBSD for that hardware patch will need to be done against -current. Not much point if nodbody's interested in it apart from me:-). Look back in the archives... This was posted around the 5.0 era: http://marc.info/?l=openbsd-bugsamp;m=132851264207109amp;w=2 -- Creamy! 3
Re: uchcom(4) did not work
/* * XXX: it is difficult to handle the line control appropriately: -* - CS8, !CSTOPB and any parity mode seems ok, but -* - the chip doesn't have the function to calculate parity -* in !CS8 mode. -* - it is unclear that the chip supports CS5,6 mode. -* - it is unclear how to handle stop bits. +* work as chip default - CS8, no parity, !CSTOPB +* other modes are not supported. */ Given that 8N1 is supported, can we not support other modes entirely in software? 7E1, and 7O1 don't need explicit hardware support. If you need 7N1, 7M1 will simulate 7N2, which the majority of hardware will work with, (an extra stop bit). If 8N1 works, and there is confusion over support for other modes, just bit bang in 8N1 mode. -- Creamy! 3
Re: IFT_L2VLAN is unused
On Thu, May 15, 2014 at 12:14:37AM +0200, Alexander Bluhm wrote: On Wed, May 14, 2014 at 11:29:20PM +0200, Henning Brauer wrote: so as discussed recently having the inet6 link-local addrs on every interface by default is stupid and a security risk. Connecting a computer to the internet is a security risk. IPv4 is on by default, and so IPv6 should be on by default. No it's not 'on by default'. I want both to be handled the same way. Then by your logic, we should assign an IPv4 link local address as well, from the 169.254.0.0/16 range. the only use case that needs config adoption: people ONLY using link-local, they will need to put +inet6 in the corresponding hostname.if file. There is a use case for running IPv6 over an interface without setting an address. Yes, there is. Configure a global IPv6 address on lo0, run ospf6d on any physical interface and it will provide connection. But that is not a good use case. Read the RFCs. IPv6 autoconfiguration with link-local addresses is useful. It can be useful, but whether it should be the default or not is another matter. Autoconfiguration in general is dangerous and unnecessary. We have it as an option. Those who want to use it have a choice. Why don't the two OpenBSD users who actually use IPv6 just use link local addresses between themselves :-))) -- Creamy! 3
Re: NOINET6 by default
On Thu, May 15, 2014 at 10:24:57AM +0200, Claudio Jeker wrote: On Thu, May 15, 2014 at 06:58:53AM +0200, J?r?mie Courr?ges-Anglas wrote: Paul de Weerd we...@weirdnet.nl writes: [...] This makes a whole lot of sense to me. Please make OpenBSD the first OS to do (this part of) v6 in a sensible way. Actually that makes me laugh. Sensible, weeeh. Let's protect our users from the dangers of IPv6 link-local addresses! Wait, what users are we talking about? We have no users, right, we have developers that break stuff, and other developers that clean up the feces. Between +inet6 and eui64 all we have are non-idiomatic or broken alternatives. Link-local addresses have been exposed since almost 15 years now, it's a good time to decide that they are persona non grata in OpenBSD land. After all, the v6 stack has had all the testing it could get, now that we know that it works well, we don't need testing anymore. What could be sensible, though, is accepting the fact that IPv6 exists, and the fact that link-local addresses are part of it, whether you have global connectivity or not. Now call me a v6 zealot, I probably live and work in an imaginary world. That reasoning would also leed to the conclusion that we should remove 'up' and 'down' from ifconfig. Since you have a network card installed and it is part of the system and should therefor be running. And by this argument it should be running IPX/SPX and NBF all the time as well. Why not run the line up/line down protocol too for backwards compatibility. There is no need to install a link-local address on an interface just because it was up-ed. But to be clear, it is supposedly required to have a link-local address if IPv6 is to be used on that interface, unless it is used as a bridge without it's own IP address. Would you like that we install link local IPv4 addresses on all interfaces? It would be possible. It would be ridiculous. It would be ridiculous, but somebody would find a use for it. Also not every interface needs a link-local address. It actually causes strange behaviours when bridge(4)-ing stuff together. This is why -inet6 was created as a hack around the fact that IPv6 is greedy taking over your network. Damn this IPv6 virus! Is IPv6 really just an evil plan by the sinister corporations and governments of the world to DDOS the entire internet, one OpenBSD box at a time? Let's face it, EBCDIC didn't cause enough confusion and headaches so let's try confusing people with IPv6, complete with IP addresses that look like an MD5 checksum gone wrong, and impossible to remember. It is time to replace the hack with a proper solution. IPv6 exists. It's useful. OpenBSD supports it very well. Do we need it enabled by default? No. -- Creamy! 3
Re: fun with smtpd, (two bugs)
On Thu, May 15, 2014 at 09:53:39PM +0059, Jason McIntyre wrote: On Thu, May 15, 2014 at 10:40:27PM +0200, Frank Brodbeck wrote: Hi Jason, On Wed, May 14, 2014 at 11:16:59PM +0059, Jason McIntyre wrote: it's still missing some . also i think we can wholly simplify the auth/auth-optional line. Heh. Thought I found all, thanks for fixing the rest. -.Op Ic auth | auth-optional | auth Ar authtable | Ic auth-optional Ar authtable +.Op Ic auth | auth-optional Aq Ar authtable the man page sates that: Both auth and auth-optional accept an optional table as a parameter. When provided, credentials are looked up in this table. but reading the new smtpd.conf(5) gives the impression that authtable is mandatory. I haven't checked the code but the following passes a check with smtpd -n listen on iwn0 tls auth listen on em0 tls auth-optional so it seems to be a valid syntax. it's why i added the word optional to the description. the syntax [table] is really ugly, and is hard to understand. Why is it ugly and hard to understand??? I think it's rather obvious that [] signifies optional and signifies the name of a table. we could do it, but i don;t want to. sometimes it's better to sacrifice being a million percent correct for clarity. Eh? How can giving incorrect information help clarity? That's a bit strange. -- Creamy! 3
Re: umsm support for Alcatel OneTouch L100V
On Fri, May 16, 2014 at 03:31:41PM +0200, ??ukasz Ratajski wrote:
Am 16.05.2014 13:10, schrieb David Coppa:
On Fri, May 16, 2014 at 1:02 PM, ??ukasz Ratajski
lukasz.rataj...@t-online.de wrote:
Attached is a diff for umsm+man page which enables support for the
Alcatel OneTouch L100V USB 2G/3G/LTE modem, known in Germany as Telekom
SpeedStick LTE II.
The storage part has to be ejected first. Connectivity tested with
userland ppp on amd64. Patch is against 5.5-STABLE.
Is it ejecting automatically?
I mean, is this using {{ USB_VENDOR_TCTMOBILE,
USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3} ?
If so, then it's ok with me.
I had to eject the umass part manually in order to access the modem.
Now, after some inspection, I am certain that I found the solution.
After manual ejection the usbdevs output changed as following:
- port 5 addr 3: high speed, power 500 mA, config 1, Mobile Broad
Band(0xf017), USBModem(0x1bbb), rev 0.00
+ port 5 addr 3: high speed, power 500 mA, config 1, Mobile Broad
Band(0x011e), USBModem(0x1bbb), rev 0.00
Apparently the umass device uses a different product ID, so I decided to
It's not unusual - I've seen Huaweii devices that behave similarly. They
have a bitmap register that enables and disabled various aspects of the
hardware, for example the micro-sd card slot and the built in flash
storage. With an AT command that I've long since forgotten, you can
clobber it and make it a 'dumb' device that only acts as a modem, (yay!
exactly what I want), and at that point it changes it's usb device ID,
(to one that is already supported by OpenBSD).
But this isn't the strangest USB thing I've seen - that was a usb HUB
that typed things at the boot prompt, behaving like a keyboard.
Actually, this worries me a bit, because how do we know that any innocent
USB device, a mouse or a keyboard for example, doesn't have firmware that
tells it to emulate a disk for 10 seconds after power is applied if it
sees that a BIOS is initialising it, and then change to an innocent device
afterwards?
--
Creamy! 3
PC-122 keyboard
Hi Miod,
(cc'ing tech@ to see if anybody else has one of these keyboards)
Is this the correct way to go about adding a sub-keymap to place
the VT switch commands on dedicated keys? For local use, I just
hacked up the standard keymap :-))). Likewise the necessary
changes to wskbd.c to process these keys without control and alt
held down is missing, because I just did a bad hack on my local
copy to make it work, (and break all other keyboards).
For those who are interested, the 122 key mainframe keyboards
have F13-F24 on the top row, (which are supported by default
in the OpenBSD console), and 10 extra function keys on the left.
There is also an extra key in the cursor section, instead of
an inverted T, the cursor movement keys are in the shape of a
plus sign, (+), with a key in the middle.
Oh, and page up, page down, and escape are in the 'correct'
positions for real programmers.
--- wsksymdef.h.origFri May 16 20:36:22 2014
+++ wsksymdef.h Fri May 16 20:44:18 2014
@@ -507,6 +507,7 @@
#define KS_Henkan 0xf115 /* Alias for Henkan_Mode */
#define KS_Muhenkan0xf116 /* Cancel Conversion */
#define KS_Mode_Lock 0xf117
+#define KS_Repeat 0xf118 /* Repeat key */
/*
* Group 2 (keypad) character in low byte
@@ -743,6 +744,7 @@
#define KB_METAESC 0x0020 /* generate ESC prefix on ALT-key */
#define KB_IOPENER 0x0040 /* f1-f12 - ESC,f1-f11 */
#define KB_MACHDEP 0x0080 /* machine dependent */
+#define KB_TERM122 0x0100 /* commands to dedicated keys on 122
key terminal keyboards */
#define KB_APPLE 0x0001 /* Apple specific layout */
#define KB_DEFAULT 0x8000 /* (attach-only) default layout */
@@ -784,6 +786,7 @@
{ KB_DVORAK,dvorak }, \
{ KB_METAESC, metaesc }, \
{ KB_IOPENER, iopener }, \
+ { KB_TERM122, term122 }, \
{ KB_MACHDEP, machdep }, \
{ KB_APPLE, apple }
--- wskbdmap_mfii.c.origFri May 16 20:35:04 2014
+++ wskbdmap_mfii.c Fri May 16 20:54:42 2014
@@ -172,6 +172,25 @@
#if !defined(WSKBD_NO_INTL_LAYOUTS)
+static const keysym_t pckbd_keydesc_term122[] = {
+/* pos command normal shifted */
+
+KC(1), KS_Escape,
+KC(59),KS_f1,
+KC(60),KS_f2,
+KC(61),KS_f3,
+KC(62),KS_f4,
+KC(63),KS_f5,
+KC(64),KS_f6,
+KC(113), KS_Cmd_Screen0,
+KC(118), KS_Cmd_Screen1,
+KC(114), KS_Cmd_Screen2,
+KC(127), KS_Cmd_Screen3,
+KC(116), KS_Cmd_Screen4,
+KC(109), KS_Cmd_Screen5,
+KC(117), KS_Cmd_Debugger,
+};
+
static const keysym_t pckbd_keydesc_de[] = {
/* pos normalshifted altgr shift-altgr */
KC(3), KS_2, KS_quotedbl,KS_twosuperior,
@@ -1096,6 +1115,7 @@
KBD_MAP(KB_US | KB_DVORAK, KB_US, pckbd_keydesc_us_dvorak),
KBD_MAP(KB_US | KB_SWAPCTRLCAPS, KB_US, pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_US | KB_IOPENER, KB_US, pckbd_keydesc_iopener),
+ KBD_MAP(KB_UK | KB_TERM122, KB_UK, pckbd_keydesc_term122),
KBD_MAP(KB_UK | KB_SWAPCTRLCAPS, KB_UK, pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_JP | KB_SWAPCTRLCAPS, KB_JP, pckbd_keydesc_swapctrlcaps),
KBD_MAP(KB_FR | KB_SWAPCTRLCAPS, KB_FR, pckbd_keydesc_swapctrlcaps),
--
Creamy! 3
Re: ifconfig segmentation fault
On Fri, May 16, 2014 at 05:29:10PM -0300, Giancarlo Razzolini wrote: Em 16-05-2014 17:18, Stuart Henderson escreveu: On 2014/05/16 17:12, Giancarlo Razzolini wrote: As I mentioned, I'm running 5.5 stable. So this might got fixed in current, I'm taking a look at the CVS commits right now to see if it was fixed. But, funny thing, I've managed to get another segmentation fault, this time from command line. While trying to replicate the bug in another machine, I've wrongly typed: ifconfig em4 -inet Instead of: ifconfig em4 -inet6 I'm unable to repeat this on amd64 5.5 release. Can you repeat it under gdb? i.e. 'sudo gdb ifconfig' then 'set args em4 -inet' (or whatever) and 'run', then if you can trigger it do a 'bt'. Just to be thrill, here follows my sha256sum of my /sbin/ifconfig: SHA256 (/sbin/ifconfig) = e1b9688f2ebf5a278408c49ac13e35479a96b883ff9891ada141470d55a1b158 If anyone running stable can check it yours is the same, I appreciate. It matches -release from the official CD. -- Creamy! 3
[Patch] Add repeat key functionality
Hello, The following patches add functionality to the console for a 'repeat' key, basically a modifier key which adjusts the typematic delay whilst held down. Usually these were found on systems which didn't have auto-repeat, but this implementation preserves the normal functionality, so that you can achieve a normal-speed repeat just by holding down the key, but a much faster auto-repeat using the dedicated 'repeat' modifier. In the patch, I've assigned it to the left control key. Any comments welcome, specifically has anybody got any suggestions for implementing this in X? I notice that a 'repeat' keysym is defined in the X sources, but it doesn't seem to be implemented in the code. Any reason this console version can't be included in the tree? -- Creamy
[Patch] Repeat key patch against 5.2-release
Diff'ed against 5.2-release
--
Creamy
--- wsksymdef.h.origTue May 24 13:23:49 2011
+++ wsksymdef.h Thu Mar 7 18:50:32 2013
@@ -507,6 +509,7 @@
#define KS_Henkan 0xf115 /* Alias for Henkan_Mode */
#define KS_Muhenkan0xf116 /* Cancel Conversion */
#define KS_Mode_Lock 0xf117
+#define KS_Repeat 0xf118
/*
* Group 2 (keypad) character in low byte
--- wskbd.c.origTue Nov 15 04:15:52 2011
+++ wskbd.c Thu Mar 7 18:49:40 2013
@@ -1538,6 +1544,19 @@
if (sc != NULL kp-command != KS_voidSymbol)
iscommand = internal_command(sc, type, kp-command,
kp-group1[0]);
+
+ /* Check for repeat key */
+ if (kp-group1[0] == KS_Repeat type==WSCONS_EVENT_KEY_DOWN)
+ {
+ sc-sc_keyrepeat_data.delN=25;
+ sc-sc_keyrepeat_data.del1=25;
+ }
+
+ if (kp-group1[0] == KS_Repeat type==WSCONS_EVENT_KEY_UP)
+ {
+ sc-sc_keyrepeat_data.delN=WSKBD_DEFAULT_KEYREPEAT_DELN;
+ sc-sc_keyrepeat_data.del1=WSKBD_DEFAULT_KEYREPEAT_DEL1;
+ }
/* Now update modifiers */
switch (kp-group1[0]) {
--- wskbdmap_mfii.c.origThu Mar 7 18:50:44 2013
+++ wskbdmap_mfii.c Thu Mar 7 18:50:57 2013
@@ -73,7 +75,7 @@
KC(26),KS_bracketleft, KS_braceleft,
KC(27),KS_bracketright, KS_braceright,
KC(28),KS_Return,
-KC(29), KS_Cmd1, KS_Control_L,
+KC(29),KS_Repeat,
KC(30),KS_a,
KC(31),KS_s,
KC(32),KS_d,
[Patch] Support F13-F24 on PC-122 terminal keyboard
The following patch adds the keycodes for F13-F24 on a standard PC-122 terminal keyboard. Doesn't seem to conflict with anything else I've found. -- Creamy --- wskbdmap_mfii.c.origTue May 24 13:23:46 2011 +++ wskbdmap_mfii.c Thu Mar 14 13:10:56 2013 @@ -130,6 +130,18 @@ KC(83),KS_KP_Delete, KS_KP_Decimal, KC(87), KS_Cmd_Screen10, KS_f11, KC(88), KS_Cmd_Screen11, KS_f12, +KC(91),KS_f13, +KC(92),KS_f14, +KC(93),KS_f15, +KC(99),KS_f16, +KC(100), KS_f17, +KC(101), KS_f18, +KC(102), KS_f19, +KC(103), KS_f20, +KC(104), KS_f21, +KC(105), KS_f22, +KC(106), KS_f23, +KC(107), KS_f24, KC(127), KS_Pause, /* Break */ KC(156), KS_KP_Enter, KC(157), KS_Cmd1, KS_Control_R,
RTC clock rollover in clock.c
Hello,
Reading /arch/amd64/isa/clock.c, I notice we have the following code,
which is also in the i386 version:
/* Kludge to roll over century. */
if ((rtc_update_century 0) ||
((cmoscentury == 19) (clockcentury == 20)
(clockyear == 2000))) {
printf(WARNING: Setting NVRAM century to %d\n,
clockcentury);
s = splclock();
mc146818_write(NULL, centb, bintobcd(clockcentury));
splx(s);
}
This is obviously to fix the 'first boot after 2000' problem where buggy
bioses would report 1900. However, the code assumes that the first boot
of such a system will actually be during the year 2000 for the fix to
work.
Given that we are now in 2013, the issue is only going to surface
if the BIOS battery fails and sets the clock back to 1996 or something
like that, (unlikely on amd64, I know, but possible on an old 486 for
example), and the correct time is then picked up from the filesystem
timestamp and used to reset the RTC, due to the filesystem time being far
in the future.
In that case, however, the NVRAM setting will remain incorrect, and this
code is isn't even going to execute, because we're checking for
clockyear == 2000 rather than clockyear = 2000.
Would the solution be to write both century and year to the NVRAM if
(cmoscentury == 19) (clockcentury == 20) ?
--
Creamy
Re: [Patch] Support F13-F24 on PC-122 terminal keyboard
Hi Miod, Thanks for looking at my patches... The following patch adds the keycodes for F13-F24 on a standard PC-122 terminal keyboard. Doesn't seem to conflict with anything else I've found. Well, it conflicts with the codes listed in the `USB HID to PS/2 Scan Code Translation Table' Yes, but that document just lists the codes that Windows translates to internally when a USB keyboard is in use. I have no reason to believe that any PS/2 device actually uses them in hardware, and good reason to believe that they don't, (and wouldn't). The unofficial 'standard' for terminal keyboard designed for Windows based terminal emulators is to send control-F1 for F13, ^F2 for F14, etc. They also send other strange combinations for the other extra keys on a terminal keyboard. The reason for this is because the terminal emulator software is designed to be usable with a 'normal' keyboard as well. Even 122 key USB keyboards do this, rather than send the USB HID codes listed in the document above. For example, Unicomp PS/2 terminal keyboards are switchable between this mode I just described, and the mode where they send the codes I listed in my patch. Unicomp USB terminal keyboards always send the multi-key sequences, and never send unique USB HID codes for the 'extra' keys. As far as I know, other manufacturers do the same thing. I have no objection against adding the F13-F24 scan codes to the pckbd and ukbd drivers; but then I'd rather go with the scan codes listed in the above document. Please don't add them at all, unless you are sure that there are real keyboards which use those codes. I have never seen one. It will cause funny behavior with a real terminal keyboard if you add those codes for F13-F24, as some of them overlap, and will cause the wrong F key to be interpreted. If your IBM keyboard uses different scancodes for the extra function keys, then it would be better to handle them with a specific submap, as already done in the declk or iopener submaps. I'm happy to use a submap for 122 key terminal keyboards, anyway. However, whilst F13-F24 have a definite use, the function keys on the left of the keyboard were traditionally used for OS-specific functions and have no standard layout. Since most of these functions do not relate to OpenBSD, I set mine to switch between virtual consoles. However, this required a hack to the kernel to disable the need to hold down control and alt to select VC, because that is hard-coded in wskbd.c. If some keymaps have dedicated keys for VC-switch, whilst others do not, we need some way to handle this if it's eventually going to be in the main tree. I am happy to produce the patch making a submap for 122 key terminal keyboards, but how would you like it done exactly? -- Creamy
Re: [Patch] Add repeat key functionality
The following patches add functionality to the console for a 'repeat' key, basically a modifier key which adjusts the typematic delay whilst held down. Is there a real use case for this feature? Fast cursor movement, scrolling, deleting. I use it every day, and can't live without it. Usually these were found on systems which didn't have auto-repeat, but this implementation preserves the normal functionality, so that you can achieve a normal-speed repeat just by holding down the key, but a much faster auto-repeat using the dedicated 'repeat' modifier. wscons already provides a key repeat functionnality, whether the underlying device supports it or not. Ah, maybe you misunderstand - it's intended as a 'fast repeat' key. You get instant and much faster repeat using this modifier, it's not meant as the only key repeat functionality, (like on the Apple ][, where none of the keys repeated, unless you held down 'repeat', which then just gave you a normal speed repeat). Any reason this console version can't be included in the tree? Yes, the way your diff works discards the non-default values the user might have set up using wsconsctl keyboard#.repeat.del[1N]. That's not a bug, it's a feature :-). It works as a 'reset' key, in case you accidently run wsconsctl keyboard.repeat.del1=10 instead of =100 :-) OK, seriously, yes it's a bug, I'll fix that and resubmit it, now that you can see how useful the functionality is... -- Creamy
Weird wscons bug (was Re: [Patch] Add repeat key functionality)
Any reason this console version can't be included in the tree? Yes, the way your diff works discards the non-default values the user might have set up using wsconsctl keyboard#.repeat.del[1N]. ...which doesn't work properly anyway, it seems: I wrote a corrected patch, tested it, and just spent 3 hours trying to work out why it broke normal functionality, only to discover that there is a bug already in the tree which stops the user-settable values from working correctly. Sure, you can set the initial and repeat delays easily enough: $ wsconsctl keyboard.repeat.deln=200 keyboard.repeat.deln - 200 Excellent. Try setting the default, though: # wsconsctl keyboard.repeat.deln.default=350 keyboard.repeat.deln.default - 200 In fact, if you check, whenever a user changes the normal value, the default value changes too. So a normal, non-root user can change the values for all of the VCs. Great. -- Creamy
Re: nc(1) shutdown(2) typo
Look at it this way. Truncated output from some query is the worst case -- it is a mysterious sometimes you get scewed behaviour. By default, I want to get the maximum. It all depends on the protocol / applications used, IMHO. What about servers that expect the client to close their writing side of the socket before processing a query? They'd use a timeout so that they don't get hung, close the socket and netcat would have received zero bytes. You get the minimum. Perhaps is that better than a random amount of data, but who said using netcat to reliably get data was a good idea in the first place? Doesn't your second point pretty much answer the first? Netcat is a diagnostic tool. Period. If you're using it in a script to do something funky, then you should know what servers you are communicating with, and accept that the whole thing is a kludge anyway. Using netcat to reliably get data is never going to be appropriate for a production system, IMHO. It's sad, because I can remember when I was using Debian, I was shown how to transfer data using only nc, on a LAN. Exactly - it's useful on a LAN where you're in control of both client and server in a closed environment, but if people are using netcat in a script as a quick and nasty way to write clients for internet based services, that is not something we should advocate, because it's wrong. -- Creamy
Re: nc(1) shutdown(2) typo
On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote: Using netcat to reliably get data is never going to be appropriate for a production system, IMHO. Wow. You sure do set the bar low. Probably a lot of people are glad that I don't accept that kind of balony. Then make the concept work. Oh, you can't, because it's broken by design. Are you seriously suggesting that an enterprise WAN solution can be built on netcat? -- Creamy
Re: nc(1) shutdown(2) typo
(trimming the CC list...) Don't worry, I'm sure 99% of subscribers send my mail to /dev/null anyway. Using netcat to reliably get data is never going to be appropriate for a production system, IMHO. Wow. You sure do set the bar low. Probably a lot of people are glad that I don't accept that kind of balony. Then make the concept work. Oh, you can't, because it's broken by design. I don't think that was the point of the discussion. Now I almost regret sending that email. I think you, and Theo, both mis-interpreted what I was trying to say. (So it's probably my fault for not expressing myself clearly). Whatever behavior you settle on for netcat, it will break somebody's script somewhere. That is the point I was trying to make. Yes, I do 'set the bar low', and I'm proud of that. I don't accept balony either. I think Theo is of the opinion that I was saying, it's broken, don't fix it. I wasn't saying that at all, a good netcat implementation is obviously desirable. The networking concept of be conservative in what you send and liberal in what you accept applies here - we should aim for a perfect netcat implementation that can be used in all circumstances. That doesn't change the fact that the concept of using it in a script instead of writing some C code is wrong, and should be discouraged. Are you seriously suggesting that an enterprise WAN solution can be built on netcat? http://www.openbsd.org/faq/pf/rdr.html#tcpproxy Sick, you'll say. Not at all. It works more reliably than the last black-box proxy I had to deal with. If the example you've linked to is the limit of what you're trying to achieve, then fine, go ahead and do it with netcat. We certainly should have an implementation that's good enough to do *that*. Guess which one was sold as an enterprise (WAN) solution? Let me just say, I really hate those sorts of phrases, I don't know why I used it, (something to do with it being 1 AM and being tired). As for black-box solutions, you really don't 'know' me, do you? If it doesn't come with source, it doesn't come anywhere near me. No closed source system is an enterprise (WAN) solution, by definition. I basically have fears that this discussion is going to lead to people trying to write something like an IMAP client using a shell script and netcat. It would never work 100%, and us expending effort to make it work 99% of the time just hurts the users who are stuck with the 1% of failiures. -- Creamy
Re: nc(1) shutdown(2) typo
Whatever behavior you settle on for netcat, it will break somebody's script somewhere. That is the point I was trying to make. And that right there is your misunderstanding. Currently, it not possible to write a script with nc that works reliably. Every script is already broken now. We're totally agreed on that point. Authors of the scripts in question may be of the opinion that it works for them, and that any change will break it. You are then claiming that it can be fixed. Show me the fix that makes all of the netcat scripts out there in the wild 'just work'. The rest of what you are yapping about does not matter. Could you qualify whether 'the rest of what you are yapping about' covers just this thread, or my subscription to -tech in general? If OpenBSD development is a closed shop, just tell me and I'll happily go back to working in isolation from the rest of you, as I have been for the last few years. If you don't like nc, don't use it. Do you think we care? Why should you? You really mis-understand my whole stance on this. -- Creamy
Re: nc(1) shutdown(2) typo
On Wed, Mar 20, 2013 at 09:21:10AM +0100, Otto Moerbeek wrote: On Wed, Mar 20, 2013 at 12:43:37AM +, Creamy wrote: On Tue, Mar 19, 2013 at 06:34:31PM -0600, Theo de Raadt wrote: Using netcat to reliably get data is never going to be appropriate for a production system, IMHO. Wow. You sure do set the bar low. Probably a lot of people are glad that I don't accept that kind of balony. Then make the concept work. Oh, you can't, because it's broken by design. Are you seriously suggesting that an enterprise WAN solution can be built on netcat? No, but at the same time I want my tools to be high quality and predictable, whether I use them for diagnostics or a quick script. I totally agree - see my later post. Maybe I was wrong to say, 'for a production system', when what I really meant was that it is wrong to use script+netcat as a generic replacement for a socket library. -- Creamy
[Patch] Update of repeat key patch, (was: Re: Weird wscons bug)
On Thu, Mar 21, 2013 at 06:05:11AM +, Miod Vallat wrote:
Excellent. Try setting the default, though:
# wsconsctl keyboard.repeat.deln.default=350
keyboard.repeat.deln.default - 200
In fact, if you check, whenever a user changes the normal value, the
default value changes too. So a normal, non-root user can change the
values for all of the VCs. Great.
No, that was a bug in wsconsctl where it would report the current repeat
rate as the default. Thanks for noticing it!
ARGH! I was looking for ages in the kernel source for a bug that didn't
exist :-)
Anyway, here are two more patches I've come up with. One is a simple
typo in a comment, the other is an updated repeat-key patch, which has
the following great features:
1. It actually works, and restores the user's custom settings, as you
pointed out that my original one didn't.
2. If you press command + repeat, it resets the rates to the defaults,
so if you accidently hose the console with wsconsctl keyboard.repeat.del1=1
it can be recovered easily.
--- wskbd.c.origTue Nov 15 04:15:52 2011
+++ wskbd.c.fixtypo Thu Mar 21 17:21:55 2013
@@ -269,7 +269,7 @@
#defineWSKBD_DEFAULT_KEYREPEAT_DEL1400 /* 400ms to start
repeating */
#endif
#ifndef WSKBD_DEFAULT_KEYREPEAT_DELN
-#defineWSKBD_DEFAULT_KEYREPEAT_DELN100 /* 100ms to between
repeats */
+#defineWSKBD_DEFAULT_KEYREPEAT_DELN100 /* 100ms between
repeats */
#endif
struct wskbd_keyrepeat_data wskbd_default_keyrepeat_data = {
--- wskbd.c.origTue Nov 15 04:15:52 2011
+++ wskbd.c Thu Mar 21 17:20:42 2013
@@ -272,12 +274,29 @@
#defineWSKBD_DEFAULT_KEYREPEAT_DELN100 /* 100ms to between
repeats */
#endif
+#ifndef WSKBD_KEY_KEYREPEAT_DEL1
+#defineWSKBD_KEY_KEYREPEAT_DEL125 /* 25ms to start
repeating */
+#endif
+#ifndef WSKBD_KEY_KEYREPEAT_DELN
+#defineWSKBD_KEY_KEYREPEAT_DELN25 /* 25ms between repeats
*/
+#endif
+
struct wskbd_keyrepeat_data wskbd_default_keyrepeat_data = {
WSKBD_KEYREPEAT_DOALL,
WSKBD_DEFAULT_KEYREPEAT_DEL1,
WSKBD_DEFAULT_KEYREPEAT_DELN,
};
+struct wskbd_keyrepeat_data wskbd_key_keyrepeat_data = {
+ WSKBD_KEYREPEAT_DOALL,
+ WSKBD_KEY_KEYREPEAT_DEL1,
+ WSKBD_KEY_KEYREPEAT_DELN,
+};
+
+struct wskbd_keyrepeat_data wskbd_store_keyrepeat_data = {
+ WSKBD_KEYREPEAT_DOALL, 0, 0,
+};
+
#if NWSMUX 0 || NWSDISPLAY 0
struct wssrcops wskbd_srcops = {
WSMUX_KBD,
@@ -1538,6 +1561,19 @@
if (sc != NULL kp-command != KS_voidSymbol)
iscommand = internal_command(sc, type, kp-command,
kp-group1[0]);
+
+ /* Check for repeat key */
+ if (kp-group1[0] == KS_Repeat type==WSCONS_EVENT_KEY_DOWN)
+ {
+ wskbd_store_keyrepeat_data = sc-sc_keyrepeat_data;
+ sc-sc_keyrepeat_data=wskbd_key_keyrepeat_data;
+ if (MOD_ONESET(sc-id, MOD_COMMAND) || MOD_ALLSET(sc-id, MOD_COMMAND1
| MOD_COMMAND2)) wskbd_store_keyrepeat_data = wskbd_default_keyrepeat_data;
+ }
+
+ if (kp-group1[0] == KS_Repeat type==WSCONS_EVENT_KEY_UP)
+ {
+ sc-sc_keyrepeat_data = wskbd_store_keyrepeat_data;
+ }
/* Now update modifiers */
switch (kp-group1[0]) {
--
Creamy
[Patch] Update Y2K bug workarounds in clock.c
All AMD64 systems should be Y2K compliant, so we can kill this code from
clock.c on this arch.
The i386 version currently only functions if the first boot after
Jan 1, 2000 is actually in the year 2000. Obviously now that we are in
2013, it's much more useful to allow the user to map
1900-1969 - 2000-2069 in the case that their BIOS doesn't allow years
past 1999 to be set directly.
The i386 version of the patch enables this behavior.
--- /usr/src/sys/arch/amd64/isa/clock.c.origTue Mar 19 22:20:59 2013
+++ /usr/src/sys/arch/amd64/isa/clock.c Thu Mar 21 18:57:36 2013
@@ -382,6 +382,8 @@
* check whether the CMOS layout is standard-like (ie, not PS/2-like),
* to be called at splclock()
*/
+
+/*
static int cmoscheck(void);
static int
cmoscheck(void)
@@ -390,70 +392,25 @@
unsigned short cksum = 0;
for (i = 0x10; i = 0x2d; i++)
- cksum += mc146818_read(NULL, i); /* XXX softc */
+ cksum += mc146818_read(NULL, i);
return (cksum == (mc146818_read(NULL, 0x2e) 8)
+ mc146818_read(NULL, 0x2f));
}
+*/
/*
- * patchable to control century byte handling:
- * 1: always update
- * -1: never touch
- * 0: try to figure out itself
- */
-int rtc_update_century = 0;
-
-/*
* Expand a two-digit year as read from the clock chip
* into full width.
- * Being here, deal with the CMOS century byte.
*/
-static int centb = NVRAM_CENTURY;
static int clock_expandyear(int);
static int
clock_expandyear(int clockyear)
{
- int s, clockcentury, cmoscentury;
+ int clockcentury;
clockcentury = (clockyear 70) ? 20 : 19;
clockyear += 100 * clockcentury;
-
- if (rtc_update_century 0)
- return (clockyear);
-
- s = splclock();
- if (cmoscheck())
- cmoscentury = mc146818_read(NULL, NVRAM_CENTURY);
- else
- cmoscentury = 0;
- splx(s);
- if (!cmoscentury) {
-#ifdef DIAGNOSTIC
- printf(clock: unknown CMOS layout\n);
-#endif
- return (clockyear);
- }
- cmoscentury = bcdtobin(cmoscentury);
-
- if (cmoscentury != clockcentury) {
- /* XXX note: saying century is 20 might confuse the naive. */
- printf(WARNING: NVRAM century is %d but RTC year is %d\n,
- cmoscentury, clockyear);
-
- /* Kludge to roll over century. */
- if ((rtc_update_century 0) ||
- ((cmoscentury == 19) (clockcentury == 20)
-(clockyear == 2000))) {
- printf(WARNING: Setting NVRAM century to %d\n,
- clockcentury);
- s = splclock();
- mc146818_write(NULL, centb, bintobcd(clockcentury));
- splx(s);
- }
- } else if (cmoscentury == 19 rtc_update_century == 0)
- rtc_update_century = 1; /* will update later in resettodr() */
-
return (clockyear);
}
@@ -560,7 +517,7 @@
{
mc_todregs rtclk;
struct clock_ymdhms dt;
- int century, diff, s;
+ int diff, s;
/*
* We might have been called by boot() due to a crash early
@@ -593,10 +550,6 @@
#endif
s = splclock();
rtcput(rtclk);
- if (rtc_update_century 0) {
- century = bintobcd(dt.dt_year / 100);
- mc146818_write(NULL, centb, century); /* XXX softc */
- }
splx(s);
}
--- clock.c.origThu Mar 21 19:12:36 2013
+++ clock.c Thu Mar 21 19:13:54 2013
@@ -543,8 +543,7 @@
/* Kludge to roll over century. */
if ((rtc_update_century 0) ||
- ((cmoscentury == 19) (clockcentury == 20)
-(clockyear == 2000))) {
+ ((cmoscentury == 19) (clockcentury == 20))) {
printf(WARNING: Setting NVRAM century to %d\n,
clockcentury);
s = splclock();
--
Creamy
Re: LC_CTYPE for spanish speaking countries
I believe we need more than one Spanish locale, because I know that spoken and written Spanish differs between Europe and South America in several ways. Unfortunately I don't know any Spanish so I can't really judge how big these difference are. Do we really need _21_ locales for Spanish, like in your diff? Wouldn't adding one or two locales for South-American dialects of Spanish be enough to cover these differences, at least where it makes a difference in terms of OpenBSD's limited functionality, and where it affects a significant chunk of ports? Are you suggesting to add individual locales as and when a significant number of translations exist in ports, (good idea), or to select a few South-American dialects to represent the whole continent, (very bad idea)? There is often more difference between South-American dialects of Spanish than between any one of them and Castillian Spanish. How would you decide which country is going to represent the whole of the continent? Why spanish is treated differently? No reason. There was simply nobody so far who was bothered by the lack of other Spanish locales. You are the first person to complain about this. That's all. Finally I don't live in Spain but in Colombia, so I should be able to use es_CO. How do you translate 'kernel panic' in to Quechua? :-) No offence, but to me, the name of a locale is just... a name. Let's try to make useful functional changes to the system. Adding locales for purely patriotic reasons seems like a waste of time to me. I agree, especially as there will always be awkward individuals like me who live in one country, but speak mostly foreign languages, and use date formats and keyboard layouts which don't correspond to any standard locale either for the country they reside in, or the foreign languages they speak. It only makes sense to add them if there is a real intention to use them. Why not just add individual locales as and when a significant number of translations exist in ports, as it gives people an incentive to translate in to their local language. -- Creamy
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 12:29:19PM +0100, Stefan Sperling wrote: On Fri, Mar 22, 2013 at 09:55:01AM +, Creamy wrote: Are you suggesting to add individual locales as and when a significant number of translations exist in ports, (good idea), or to select a few South-American dialects to represent the whole continent, (very bad idea)? A mix of the two. I don't want to make technical decisions based on politics. Agreed. I'd like to recognize and fix situations where people are missing functionality from the system because their language of choice is not represented properly. It's not a black and white decision, it's a trade-off. Agreed - as pointed out in a previous message in this thread, for the time being, more benefit would come from improving es_ES. Any Spanish speaker who doesn't understand English would benefit significantly from this, and in any case, they are in the best position to provide us with a further translation for their local dialect. Also, I think that extending the locale implementation (such as adding support for LC_TIME, LC_COLLATE, etc) is much more important at this stage than adding additional files to /usr/share/locale. Yes. There is often more difference between South-American dialects of Spanish than between any one of them and Castillian Spanish. How would you decide which country is going to represent the whole of the continent? That's a tough question, and I really don't mean to alienate people who speak any of these dialects. But I'd like to avoid the situation where typing the name of a locale is something that people associate with their own identity. Because then, there would be no reason at all to stop adding more locales until the /usr filesystem is full. I strongly agree here... Systems like Debian ask their users to generate some selection of locales during the installation process. I don't think it is a good idea to ask users to make that kind of choice during system installation. But it's a consequence of the fact that Debian has too many locales. ... and here ... No offence, but to me, the name of a locale is just... a name. Let's try to make useful functional changes to the system. Adding locales for purely patriotic reasons seems like a waste of time to me. I agree, especially as there will always be awkward individuals like me who live in one country, but speak mostly foreign languages, and use date formats and keyboard layouts which don't correspond to any standard locale either for the country they reside in, or the foreign languages they speak. Exactly. I'm a native speaker of German, but learned a significant amount of English in Ireland during my teenage years forcing me to slowly recover some chunks of my memory of German when I got back. All my computers speak English to me and I speak English to them, whether or not people around me speak German to me. I type on a US keyboard (cannot type on German ones for the life of me), and prefer to read dates with days given before months because that is what I'm used to. My preferred personal locale would probably be called something like en_IE_de_DE_kbd_US.UTF-8. ... for that exact reason! I think that there are broadly two types of people who are interested in internationalisation - those who are monolingual and only speak a language other than English, and those who work in mixed environments on a regular basis. Each group will have different views on what is a priority and what isn't. If you have ever been asked to type Spanish on a badly configured Japanese keyboard, on an old version of Windows NT which doesn't allow any real customisation of the keymap, you will understand. (Amasingly, typing Japanese on the keyboard was easy, despite it being mis-configured, as it was handled by a proprietary userland application). It only makes sense to add them if there is a real intention to use them. Why not just add individual locales as and when a significant number of translations exist in ports, as it gives people an incentive to translate in to their local language. I'd like to avoid making up a set of rules about when new locales can be added. I think we should discuss this on a case-by-case basis, and allow people who are genuinely missing functionality to make their case. Sure, but obviously the existance of a large number of translations adds weight to their case. -- Creamy
Re: Typos in net/bpf.h
On Fri, Mar 22, 2013 at 03:53:07PM +0100, Gabriel Linder wrote: While learning how to use BPF I fumbled on this, clarification is needed imho. ok ? Index: sys/net/bpf.h === RCS file: /cvs/src/sys/net/bpf.h,v retrieving revision 1.43 diff -u -r1.43 bpf.h --- sys/net/bpf.h26 Mar 2012 19:37:42 -1.43 +++ sys/net/bpf.h22 Mar 2013 14:48:21 - @@ -73,12 +73,12 @@ }; /* - * Struct return by BIOCVERSION. This represents the version number of + * Struct returned by BIOCVERSION. This represents the version number of * the filter language described by the instruction encodings below. - * bpf understands a program iff kernel_major == filter_major + * bpf understands a program if kernel_major == filter_major This is not exactly a typo, I believe it means, 'if and only if'. However, iff is a bad term to use precisely for this reason, so please spell it out in full :-). -- Creamy
Re: Typos in net/bpf.h
On Fri, Mar 22, 2013 at 10:38:25AM -0600, Theo de Raadt wrote: On 03/22/13 17:25, Philip Guenther wrote: On Fri, Mar 22, 2013 at 7:53 AM, Gabriel Linder lin...@jeuxvideo.com wrote: - * bpf understands a program iff kernel_major == filter_major + * bpf understands a program if kernel_major == filter_major Not a typo: iff is a shorthand for if and only if that was inherited from the mathematics community. I did not know that, thanks. Maybe it should be spelled in full letters then ? iff is a useful technical word which avoids us typing it out in full every time. flamebait iff you know what it means :-) /flamebait -- Creamy
F21-F24 escape codes in wsemul_vt100_keys.c
Hi Miod,
We need to generate escape codes for the extra function keys,
otherwise wsemul_vt100_keys.c tries to generate an ASCII code from
the keysym value, which gives us ^T ^U ^V ^W, which is not
particularly helpful.
There are no standard escape codes, and those for F1-F5 don't match
our defaults in xterm anyway, so I've just continued the sequence,
and am working on an updated termcap to support them anyway.
--- wsemul_vt100_keys.c.origFri Mar 22 17:46:29 2013
+++ wsemul_vt100_keys.c Fri Mar 22 17:50:00 2013
@@ -58,6 +58,10 @@
\033[32~,
\033[33~,
\033[34~, /* F20 */
+ \033[35~, /* F21 */
+ \033[36~, /* F22 */
+ \033[37~, /* F23 */
+ \033[38~, /* F24 */
};
static const char *vt100_pfkeys[] = {
@@ -86,11 +90,11 @@
struct wsemul_vt100_emuldata *edp = cookie;
static char c;
- if (in = KS_f1 in = KS_f20) {
+ if (in = KS_f1 in = KS_f24) {
*out = vt100_fkeys[in - KS_f1];
return (5);
}
- if (in = KS_F1 in = KS_F20) {
+ if (in = KS_F1 in = KS_F24) {
*out = vt100_fkeys[in - KS_F1];
return (5);
}
--
Creamy
[patch] tic man page file path error
Hello Creamy fans! Here's a patch to change the tic man page to actually state the correct terminfo directory... --- /usr/src/usr.bin/tic/tic.1.orig Sat Mar 23 20:01:18 2013 +++ /usr/src/usr.bin/tic/tic.1 Sat Mar 23 20:02:11 2013 @@ -31,7 +31,7 @@ .\ $Id: tic.1,v 1.15 2010/09/02 09:00:01 sobrado Exp $ .TH tic 1 .ds n 5 -.ds d /usr/share/misc/terminfo +.ds d /usr/share/terminfo .SH NAME \fBtic\fR - the \fIterminfo\fR entry-description compiler .SH SYNOPSIS -- Creamy
[patch] change identd options to match advice elsewhere
In /etc/rc.conf, we recommand to use the -elo flags, but in fact, when we start identd from inetd, we only use -el. This patch adds the -o flag to /etc/inetd.conf to match. --- /usr/src/etc/inetd.conf.origSat Mar 23 20:17:30 2013 +++ /usr/src/etc/inetd.conf Sat Mar 23 20:17:42 2013 @@ -12,8 +12,8 @@ #uucpd stream tcp6nowait root/usr/libexec/uucpd uucpd #fingerstream tcp nowait _fingerd /usr/libexec/fingerd fingerd -lsm #fingerstream tcp6nowait _fingerd /usr/libexec/fingerd fingerd -lsm -ident stream tcp nowait _identd /usr/libexec/identd identd -el -ident stream tcp6nowait _identd /usr/libexec/identd identd -el +ident stream tcp nowait _identd /usr/libexec/identd identd -elo +ident stream tcp6nowait _identd /usr/libexec/identd identd -elo 127.0.0.1:comsat dgram udp waitroot/usr/libexec/comsat comsat [::1]:comsat dgram udp6waitroot/usr/libexec/comsat comsat #ntalk dgram udp waitroot/usr/libexec/ntalkd ntalkd -- Creamy
Re: [patch] change identd options to match advice elsewhere
On Sat, Mar 23, 2013 at 05:13:14PM -0430, Andres Perera wrote: the current version of src/etc/inetd.conf is 1.61. yours is an old one Sorry, missed that. However, although it's now disabled by default, we still have conflicting advice in the two places about the suggested options to use. Which should change, remove -o in the rc.conf comment, or add -o in the, (disabled), lines in inetd.conf? -- Creamy
Re: [patch] tic man page file path error
On Sat, Mar 23, 2013 at 05:31:15PM -0430, Andres Perera wrote: $ ident src/lib/libcurses/tinfo/read_bsd_terminfo.c src/lib/libcurses/tinfo/read_bsd_terminfo.c: $OpenBSD: read_bsd_terminfo.c,v 1.18 2010/01/12 23:22:06 nicm Exp $ $ grep -B2 -nw _PATH_TERMINFO src/lib/libcurses/tinfo/read_bsd_terminfo.c 22-#include term_entry.h 23- 24:#define _PATH_TERMINFO /usr/share/misc/terminfo -- 60- 61-/* Finally we check the system terminfo file */ 62:*fname++ = _PATH_TERMINFO; $ ls /usr/share/misc/terminfo ls: /usr/share/misc/terminfo: No such file or directory $ ls /usr/share/terminfo 1 2 3 4 5 6 7 8 9 A E L M N P Q X a b c d e f g h i j k l m n o p q r s t u v w x z -- Creamy
pppd-invoked scripts to run as root or not?
From the pppd man page: 1163:.Sh SCRIPTS 1164-.Nm 1165-invokes scripts at various stages in its processing which can be 1166-used to perform site-specific ancillary processing. 1167-These scripts are usually shell scripts, but could be executable code files 1168-instead. 1169-.Nm 1170-does not wait for the scripts to finish. 1171-The scripts are executed as root (with the real and effective user ID set to 0), No, they are not. Which is wrong, the man page, or the behavior of pppd? -- Creamy
Re: goodbye to some isa devices
Sorry, but I think there is some seriously strange reasoning going on here. It's not so much that we spend time maintaining the source, but I do spend time compiling it. Err, don't you use a custom kernel configuration? Unless you're working on those drivers, why are you compiling them in anyway? Yes, I've read the FAQ, and I know we're all supposed to be using the GENERIC kernel, but who does? Mine is customisted beyond recognition. And I have to download it (3 times!) every time I install a new snapshot. Cumulatively, I've probably spent hours of my life waiting for these drivers' bits to go from here to there. I will selfishly claim that if I save five minutes of time this year by not compiling these files, that right there is more benefit than retaining support. There is certainly a case that five minutes multiplied by the number of OpenBSD users does add up to a significant amount of wasted time, but why are you assuming that these disabled by default drivers are not used by a significant number of people? I targeted disabled devices figuring they were least likely to be missed, I disagree here, there are plenty of enabled devices that nobody owns or cares about. The two issues are completely separate. but I honestly question the utility of any of these ISA network and SCSI drivers. Perhaps somebody who is new to coding might be able to learn something from them? Besides, at this point, due to adding so many new drivers (kernel size has more than doubled in last ten years) the minimum RAM requirement is basically past ISA only machines. This is an issue for the install media. After that, you should be running a custom kernel if you're using an obsolete machine. The segment of machines that lack PCI but support 32M or more of RAM is very narrow. True. And unlike sparc or vax, I don't think running OpenBSD on some ancient 486 is historically interesting. But OpenBSD doesn't run on the really interesting Vaxen, anyway. If it did, I'd have an 11-series Vax here tomorrow. I even have some 9-track tape in the loft, just waiting for it. The truth is, running OpenBSD on a MicroVax, is no more fun than an old 486, it's just slower. boot loginout.exe oh, what nostalgia. Not. Have you ever used those machines, with their crashing removable disk packs. and tape drives that unwound 2400 feet of tape all over the place in just a few seconds? You're seeing them through rose-tinted glasses if you did. Not to mention that the decent Vaxen need three phase power. Great. Looking to the future, when are we going to drop 486 support, anyway? -- Creamy
Re: goodbye to some isa devices
On Tue, Mar 26, 2013 at 10:50:40PM +0400, Franco Fichtner wrote: Nobody in their right mind would have such a system as mission critical infrastructure. :) What, like using a Honeywell 316 as a nuclear power station reactor temperature monitor in to the early 2000s, until it's hard disk failed? Don't worry, it's been replaced with a couple of PDP11/70's, so we can all sleep well at night. N.B. This one *isn't* a joke. -- Creamy
Re: goodbye to some isa devices
On Tue, Mar 26, 2013 at 09:00:39PM +0400, Franco Fichtner wrote: On Mar 26, 2013, at 6:26 PM, Creamy cre...@nocrater.com wrote: but I honestly question the utility of any of these ISA network and SCSI drivers. Perhaps somebody who is new to coding might be able to learn something from them? There is such a vast amount of code in the different BSD flavours alone that it becomes very unlikely someone will stumble upon ISA code bits, especially if one is a novice programmer. And how many of those are old enough to have seen what ISA looks like nowadays? I can see your reasoning, but I was thinking more along the lines of old school coders who are perhaps alien to unix systems programming, and/or C in general. Maybe there aren't as many of them around as I imagined. Looking at diffs which remove ISA relevant stuff is probably the only time they will see it -- that's educational *and* teducational at the same time. Sorry for the bad pun. On reflection, it's not a good reason in itself to keep them in the tree. Looking to the future, when are we going to drop 486 support, anyway? Now, that's a more interesting thing ask. How much of the hardware survives now, anyway? I mean at least the old Vaxen were, (and are), maintainable. 486 motherboard dies, what do you do? Chances are it's a multi-layer pcb, so if traces go bad within it, a repair is going to be almost impossible. On Tue, Mar 26, 2013 at 12:18:03PM -0400, Ted Unangst wrote: On Tue, Mar 26, 2013 at 14:26, Creamy wrote: but I honestly question the utility of any of these ISA network and SCSI drivers. Perhaps somebody who is new to coding might be able to learn something from them? The last thing this world needs is more programmers who learned to code by reading old unmaintained ISA drivers. Try to see both sides of it though, for somebody like myself who has a background in embedded systems, and learned to code by writing z80 assembler. When I first came to unix systems programming and C in general, I could follow the logical flow of what I was reading, even though I couldn't write a line of compatible code myself, (some would say I still can't ;-) ). I learned a lot by looking at things like drivers for Hercules mono cards, which basically consisted of mode setting and a dumb framebuffer. I doubt whether today's generation in a similar situation would learn much from looking at any of the code for the latest ATI or Nvidia cards. -- Creamy
Re: goodbye to some isa devices
On Wed, Mar 27, 2013 at 10:43:53AM +, Stuart Henderson wrote: On 2013/03/26 18:06, Creamy wrote: On Tue, Mar 26, 2013 at 09:00:39PM +0400, Franco Fichtner wrote: On Mar 26, 2013, at 6:26 PM, Creamy cre...@nocrater.com wrote: Looking to the future, when are we going to drop 486 support, anyway? Now, that's a more interesting thing ask. How much of the hardware survives now, anyway? I mean at least the old Vaxen were, (and are), maintainable. 486 motherboard dies, what do you do? Chances are it's a multi-layer pcb, so if traces go bad within it, a repair is going to be almost impossible. Some of the 486-class embedded boards are quite solid hardware and not likely to die anytime soon. Agreed, but my experience was that those of us who were in the habbit of purchasing kit with decent build quality, in preference to the latest 'features', back in the day, were also the ones who tended to sell and replace it. The old boards that people are trying to keep in operation now, ironically, tend to be the rubbish ones. At least that's my experience, but others' may differ. What advantage would there be to dropping 486 support anyway? In itself, perhaps not much, I very much doubt whether we'd see any use from being able to build the default distribution with 586+ compiler options, for example. However, on a practical level, if we took the decision to kill 486 support, we could, in effect, loose 99% of the ISA-related code, as excluding a few specialised pieces of hardware, (which OpenBSD doesn't support, and probably never will), ISA pretty much died by the 586 era, (as did VL-bus). As I pointed out in a previous post, we still have a Y2K workaround in the clock code, which is pointless on AMD64, anyway, and just a hang-over from taking the code straight from the i386 port. How many 586+ machines needed this workaround, anyway? Maybe some of the original P60 systems did, I honestly don't remember, but the number would be very small, if it is 0. I'm not claiming that dropping 486 support is the right thing to do right now, but I think it should be in our minds as an option. Look to the future, at what point did booting from CD-ROM become standard in BIOSes? I only used a few select brands of kit back then, generally the higher quality ones, so maybe I am off the mark here, but I never remember seeing a second-generation Pentium, (I.E. P75+), that lacked this feature. So, maybe we could eventually loose the need for boot floppy support, and we could overhaul the instructions in the official disc set, and make better use of those pages explaining the floppy install, which nobody uses, for something more useful. We could probably also loose the force-CHS code in the bootloader, which would save some very precious space, and allow us to use it for something more useful. For example, I'm obviously not using that on AMD64, so I added the feature to force booting of partition 3, regardless of which is flagged as active. Why? I was messing around with some assembler stuff on the raw hardware, (effectively writing my own OS, if you want to call it that, but all it did was print some text using the BIOS, it's a long story why I'm doing this, I'll tell the interested parties, (I.E. nobody), some other time), and I had flagged partition 0 as active, and had to boot from the 5.2 CD to set it back, as my 'os' has no fdisk program, (or any programs for the foreseeable future). However, it struck me that somebody dual-booting with Windows would probably have the same problem, because as far as I know you can't set an arbitrary partition active with fdisk in Windows, but I really don't know or care, because I don't use it. So, you see, killing 486 support might be no advantage in itself, but it opens up possibilities further down the line, that won't exist all the time we're dragging all this old stuff along with us. -- Creamy
Re: goodbye to some isa devices
Hi, Please, don't do this. What exactly? You quoted my entire mail, but didn't narrow down exactly which of my suggestions would cause problems for you. I've jumped from OpenBSD to NetBSD boat when SCSI driver were rewritten to the new version (between 3.1-stable and 3.2-stable), and my very branded HP NetServer with AIC-7770 (which can work on IRQ 14 when primary IDE channel is disabled or IRQ 15 when IDE channel is enabled, no other IRQs are possible) ceased to work. For now, my old Acer netbook with AMD Turion processor is too old for NetBSD (my touchpad doesn't work out of the box). That's why I'm reading this mail list. I searched the archives for -tech and -misc, but couldn't find any posts from you about this. Both sound like problems that would be fairly easily addressed. Have you tried to boot any OpenBSD version since 3.2 on the HP? Just FYI. Well, that's the whole point of this list :-). I really wasn't suggesting dropping 486, ISA, or boot floppy support any time soon. I assume that the HP is a 486, by the way? The NetServer line covers a lot of machines. In fact, to everybody else who is reading this, doesn't it just point out that 486 support is, effectively, already broken, (as I suspected), because the devices that typically go with machines of that era are suffering bit-rot in the tree? -- Creamy
Re: goodbye to some isa devices
On Wed, Mar 27, 2013 at 08:05:47PM +, Miod Vallat wrote: In fact, to everybody else who is reading this, doesn't it just point out that 486 support is, effectively, already broken, (as I suspected), because the devices that typically go with machines of that era are suffering bit-rot in the tree? Absolutely not. First, 80486 support is not broken (but an FPU is required); You mis-understand, I am fully aware that the CPU itself is fully supported - my point was that it's likely that any 486 as a whole is more than likely to contain hardware that has issues which are going un-noticed because people are not using the code. second, isa drivers receiving few, if any, attention, doesn't mean they are no longer working. Where did I claim that, exactly? Ever heard of `if it ain't broke, don't touch it'? Well, maybe Alexey would have been happy for somebody to touch his SCSI driver and fix it, why don't you do it for him? Somebody broke it almost 20 releases ago, and guess what, from what I can gather it's still broken. So, if it IS broken, DO fix it. Or are you just trolling for the sake of it? I didn't expect that from you, frankly. Other people have been rude to me off-list, but I thought you were above that. Really, this community has an attitude problem - and you *need* more developers, believe me, you shouldn't be trying to scare them away. -- Creamy
Re: goodbye to some isa devices
Soekris NET4501 are still in use, and they are based upon 80486 cores. `Key' ISA devices such as wdc are still heavily tested as pcmcia or such attachments on i386 and non-i386 platforms. Other devices such as com(4), pckbc(4), still exist on many systems, even if they are no longer on extension boards. Even boards such as ISA xl(4) or eg(4) receive occasional testing several times a year. I think I clearly implied that some of the 'Key' ISA devices would have to stay, when I said '99% of the ISA-related code'. I never said, ISA can cease to exist, nor that 486 support should be removed now. What you're suggesting is a small part of the ISA code in the tree. ...and note that I've been working on the pckbc code for the last couple of weeks, so I should be fully aware of it's existance. Don't worry, I won't bother you with any patches, I know you ignored the last one, even though I fixed it as you mentioned. second, isa drivers receiving few, if any, attention, doesn't mean they are no longer working. Where did I claim that, exactly? ``broken (as I suspected)'', followed by ``suffering bit-rot'' does not exactly convey the idea of something in working condition, does it? Why is Alexey's HP Netserver running NetBSD, then? You've just had it pointed out to you in another post that there are dregs of the Token Ring support still in the GENERIC config - how many eyes are actually looking at this code? Who claimed that my repeat key patch broke something that was already broken? My comments of broken and suffering bit-rot don't apply to all ISA code, but certainly do to some of it. Ever heard of `if it ain't broke, don't touch it'? Well, maybe Alexey would have been happy for somebody to touch his SCSI driver and fix it, why don't you do it for him? Somebody broke it almost 20 releases ago, and guess what, from what I can gather it's still broken. I remember very well ahc(4) being broken on older chips for a couple releases because the developer in charge had difficulties getting the code to work with all generations of the chip, but it got better after a few years. There is no evidence the OP has ever tried OpenBSD again after switching operating systems on his system. So that's one 486 user who doesn't care whether OpenBSD supports his system or not. See what I mean? Or are you just trolling for the sake of it? I didn't expect that from you, frankly. Other people have been rude to me off-list, but I thought you were above that. So what? To me, you often sound like a troll. Miod, you seem like an all-right bloke, and I don't want to create bad feelings, but you're insulting me on a public mailing list, because I dare to bring up something you object to. Other people have been rude to me in private mail, because my views differ from theirs. This represents a small minority of the OpenBSD development community, I know, but if I was really just here to troll, why would I have posted so many patches and fixes in the two weeks that I have been subscribed? Why does it seem like everybody is obsessed with me on this mailing list at times? Ever since I joined, I have seen a flood of hits from OpenBSD based browsers in the logs for the nocrater.com site, even though it's off-line at the moment and re-directing everybody to the mobile site, which is making us look really unprofessional, I know, but I've been spending so much time contributing to this list that I haven't had time to fix it. I've also had private mails quizzing me as to who I am, (who cares, if I'm writing good code?), and general written abuse, mostly off-list. Get a life. -- Creamy
