Re: base system multi-booting in MBR
Very interesting. Thanks for the information. -- Alexei Malinin On 02/01/18 04:39, YASUOKA Masahiko wrote: > On Wed, 31 Jan 2018 17:05:57 -0500 > Bryan Steele wrote: >> On Wed, Jan 31, 2018 at 10:41:48PM +0100, Christian Weisgerber wrote: >>> Alexei Malinin: >>> >>>> If the base system supported multi-booting in MBR would the community be >>>> interested in it? >>> It should be easy to adapt FreeBSD's boot0. I don't remember any >>> demand for it, and now MBR is on its way out... >>> >>> https://svnweb.freebsd.org/base/head/stand/i386/boot0/boot0.S >>> >>> boot0 + boot0cfg might be something for the ports tree. >>> >>> -- >>> Christian "naddy" Weisgerber na...@mips.inka.de >> OpenBSD's boot(8) already supports multi-boot (chainloading PBR), see >> the "machine boot" command, note that this is different from "boot". >> >> http://man.openbsd.org/man8/amd64/boot.8#COMMANDS >> >> There's no support for this in efiboot, but with that you can instead >> use an UEFI shell, or some other EFI loader, like rEFInd. > Also we can use "machine exit". This leads most firware invoke next boot > loader. > > --yasuoka
base system multi-booting in MBR
Hello. If the base system supported multi-booting in MBR would the community be interested in it? -- Alexei Malinin
realpath additions
Hello.
I'm not sure but it seems to me that there are several missed things:
- checking path against NULL,
- setting errno to ENOMEM in case of malloc() failure,
- clarification in comments.
--
Alexei Malinin
--- src/lib/libc/stdlib/realpath.c.orig Tue Oct 13 23:55:37 2015
+++ src/lib/libc/stdlib/realpath.c Mon Mar 21 15:16:52 2016
@@ -41,8 +41,9 @@
* char *realpath(const char *path, char resolved[PATH_MAX]);
*
* Find the real name of path, by removing all ".", ".." and symlink
- * components. Returns (resolved) on success, or (NULL) on failure,
- * in which case the path which caused trouble is left in (resolved).
+ * components. Returns (resolved) on success; sets (errno) and returns
+ * (NULL) on failure, in which case the path which caused trouble
+ * is left in (resolved).
*/
char *
realpath(const char *path, char *resolved)
@@ -54,6 +55,11 @@
int serrno, slen, mem_allocated;
char left[PATH_MAX], next_token[PATH_MAX], symlink[PATH_MAX];
+ if (path == NULL) {
+ errno = ENOENT;
+ return (NULL);
+ }
+
if (path[0] == '\0') {
errno = ENOENT;
return (NULL);
@@ -63,8 +69,10 @@
if (resolved == NULL) {
resolved = malloc(PATH_MAX);
- if (resolved == NULL)
+ if (resolved == NULL) {
+ errno = ENOMEM;
return (NULL);
+ }
mem_allocated = 1;
} else
mem_allocated = 0;
Re: [PATCH] add F13-F24 and colour support to console terminfo
On 11/09/15 11:50, Tati Chevron wrote: > On Mon, Nov 09, 2015 at 08:23:08AM +, Nicholas Marriott wrote: >> On Sun, Nov 08, 2015 at 09:01:52PM +, Tati Chevron wrote: >>> Is there any reason why the OpenBSD installer still defaults to a >>> terminal type of vt-220 for the VGA framebuffer console, and doesn't >>> even suggest pccon as an alternative? >> >> In the installer itself? vt220 works fine and reliably and - importantly >> - is small and fits on the ramdisks. Who needs to press F13 in the >> installer? > > Agreed, I didn't mean the installer itself, that does work fine with > vt220. > >> If you mean in /etc/ttys, this has been discussed before and mostly the >> reason it has stayed is that terminfo entries propagate very slowly and >> vt220 is available everywhere, no matter if the user ssh to some ancient >> OS. It's easy to change anyway. > > Ah, then this is a documentation issue - I always assumed that the > terminal type specified in the installer was propogated to /etc/ttys > during the install, and used as a default for the console. > > It is indeed easy to change, but the existance of pccon isn't exactly > widely documented. To be honest, I knew about it, but seeing that it > was broken and not used by default in the installer, nor on the > console after installation, I assumed that it was abandoned and > unmaintained. It's not broken. It is stable :) I use it every day.I'm waiting for worldwide distribution of the pccon* terminfo entries :)) -- Alexei Malinin
change from vt220 to pccon0 for AMD/Intel consoles
Hello. There are pccon* terminal descriptions for AMD/Intel PC consoles in /etc/termcap.I have been using them on various computers since 2011 without problems. I suggest to use pccon0 instead of vt220 by default for amd64 and i386because vt220 has not good support of navigation and function keys oftypical PC keyboard. History of pccon*: http://marc.info/?l=ncurses-bug&m=131825802104588&w=2 http://marc.info/?l=openbsd-misc&m=132125411729722&w=2 -- Alexei Malinin diff -dur src.orig/etc/etc.amd64/ttys src/etc/etc.amd64/ttys --- src.orig/etc/etc.amd64/ttys Wed Jan 9 20:39:42 2008 +++ src/etc/etc.amd64/ttys Wed Jul 15 16:14:29 2015 @@ -3,19 +3,19 @@ # # name getty typestatus comments # -console"/usr/libexec/getty std.9600" vt220 off secure -ttyC0 "/usr/libexec/getty std.9600" vt220 on secure -ttyC1 "/usr/libexec/getty std.9600" vt220 on secure -ttyC2 "/usr/libexec/getty std.9600" vt220 on secure -ttyC3 "/usr/libexec/getty std.9600" vt220 on secure -ttyC4 "/usr/libexec/getty std.9600" vt220 off secure -ttyC5 "/usr/libexec/getty std.9600" vt220 on secure -ttyC6 "/usr/libexec/getty std.9600" vt220 off secure -ttyC7 "/usr/libexec/getty std.9600" vt220 off secure -ttyC8 "/usr/libexec/getty std.9600" vt220 off secure -ttyC9 "/usr/libexec/getty std.9600" vt220 off secure -ttyCa "/usr/libexec/getty std.9600" vt220 off secure -ttyCb "/usr/libexec/getty std.9600" vt220 off secure +console"/usr/libexec/getty std.9600" pccon0 off secure +ttyC0 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC1 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC2 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC3 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC4 "/usr/libexec/getty std.9600" pccon0 off secure +ttyC5 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC6 "/usr/libexec/getty std.9600" pccon0 off secure +ttyC7 "/usr/libexec/getty std.9600" pccon0 off secure +ttyC8 "/usr/libexec/getty std.9600" pccon0 off secure +ttyC9 "/usr/libexec/getty std.9600" pccon0 off secure +ttyCa "/usr/libexec/getty std.9600" pccon0 off secure +ttyCb "/usr/libexec/getty std.9600" pccon0 off secure tty00 "/usr/libexec/getty std.9600" unknown off tty01 "/usr/libexec/getty std.9600" unknown off tty02 "/usr/libexec/getty std.9600" unknown off diff -dur src.orig/etc/etc.i386/ttys src/etc/etc.i386/ttys --- src.orig/etc/etc.i386/ttys Wed Jan 9 20:39:42 2008 +++ src/etc/etc.i386/ttys Wed Jul 15 16:14:42 2015 @@ -3,19 +3,19 @@ # # name getty typestatus comments # -console"/usr/libexec/getty std.9600" vt220 off secure -ttyC0 "/usr/libexec/getty std.9600" vt220 on secure -ttyC1 "/usr/libexec/getty std.9600" vt220 on secure -ttyC2 "/usr/libexec/getty std.9600" vt220 on secure -ttyC3 "/usr/libexec/getty std.9600" vt220 on secure -ttyC4 "/usr/libexec/getty std.9600" vt220 off secure -ttyC5 "/usr/libexec/getty std.9600" vt220 on secure -ttyC6 "/usr/libexec/getty std.9600" vt220 off secure -ttyC7 "/usr/libexec/getty std.9600" vt220 off secure -ttyC8 "/usr/libexec/getty std.9600" vt220 off secure -ttyC9 "/usr/libexec/getty std.9600" vt220 off secure -ttyCa "/usr/libexec/getty std.9600" vt220 off secure -ttyCb "/usr/libexec/getty std.9600" vt220 off secure +console"/usr/libexec/getty std.9600" pccon0 off secure +ttyC0 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC1 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC2 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC3 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC4 "/usr/libexec/getty std.9600" pccon0 off secure +ttyC5 "/usr/libexec/getty std.9600" pccon0 on secure +ttyC6 "/usr/libexec/getty std.9600" pccon0 off secure +ttyC7 "/usr/libexec/getty std.9600" pccon0 off secure +ttyC8 "/usr/libexec/getty std.9600" pccon0 off secure +ttyC9 "/usr/libexec/getty std.9600" pccon0 off secure +ttyCa "/usr/libexec/getty std.9600" pccon0 off secure +ttyCb "/usr/libexec/getty std.9600" pccon0 off secure tty00 "/usr/libexec/getty std.9600" unknown off tty01 "/usr/libexec/getty std.9600" unknown off tty02 "/usr/libexec/getty std.9600" unknown off
Re: Cronyx Omega-PCI (8 port serial)
Hello.
Please tell me how to add code to com_puc_attach() of
sys/dev/puc/com_puc.c from OpenBSD-5.1 so the kernel
can work with the known UART type without device probing?
Perhaps my way is not quite correct, in this case
please tell me which way to go.
void
com_puc_attach(parent, self, aux)
struct device *parent, *self;
void *aux;
{
struct com_softc *sc = (void *)self;
struct puc_attach_args *pa = aux;
const char *intrstr;
/* Grab a PCI interrupt. */
intrstr = pa->intr_string(pa);
sc->sc_ih = pa->intr_establish(pa, IPL_TTY, comintr, sc,
sc->sc_dev.dv_xname);
if (sc->sc_ih == NULL) {
printf(": couldn't establish interrupt");
if (intrstr != NULL)
printf(" at %s", intrstr);
printf("\n");
return;
}
printf(" %s", intrstr);
sc->sc_iot = pa->t;
sc->sc_ioh = pa->h;
sc->sc_iobase = pa->a;
if (PUC_IS_COM_MUL(pa->type))
sc->sc_frequency = COM_FREQ * PUC_COM_GET_MUL(pa->type);
else
sc->sc_frequency = COM_FREQ * (1 << PUC_COM_GET_POW2(pa->type));
+/* If this is a known card, provide the UART type. */
+if (PCI_VENDOR(?) == PCI_VENDOR_PLX &&
+PCI_PRODUCT(?) == PCI_PRODUCT_PLX_CRONYX_OMEGA)
+sc->sc_uarttype = COM_UART_ST16C654;
com_attach_subr(sc);
}
--
Alexei Malinin
> Original Message
> Subject: Cronyx Omega-PCI (8 port serial)
> Date: Mon, 13 Aug 2012 15:22:28 +0400
> From: Alexei Malinin
> To: m...@openbsd.org
>
>
> Hello.
>
> Recently I tried to use multiport serial card
> "Cronyx Omega-PCI (8 port serial)" with
> i386 OpenBSD-5.1 and noticed that the kernel
> detected serial port chips of this card
> incorrectly as "st16650, 32 byte fifo" (dmesg)
> but not "st16c654, 64 byte fifo" (as it was,
> for example, in OpenBSD-4.2).
>
> I checked the current manual for puc.4
> (http://www.openbsd.org/cgi-bin/cvsweb/src/share/man/man4/puc.4?rev=1.46;content-type=text%2Fplain):
> Cronyx Omega-PCI is supported by OpenBSD.
>
> I checked the current src/sys/dev/pci/puc.c and
> noticed that the appropriate code for "Cronyx Omega-PCI"
> was removed in revision 1.20
> (http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/puc.c.diff?r1=1.19;r2=1.20).
>
> Is it possible to recover the removed code?
>
>
> --
> Alexei Malinin
puc.4 patch
Hello. Multiport serial adapter Cronyx Omega-PCI (based on EXAR ST16C654 chips, see http://www.cronyx.ru/hardware/ompci.html) is supported by OpenBSD since version 4.1 but in the manual (puc.4) there is no mention about this adapter. There is my patch below. -- Alexei Malinin --- src/share/man/man4/puc.4.orig Sat Mar 5 17:48:26 2011 +++ src/share/man/man4/puc.4Sat Mar 5 17:52:55 2011 @@ -64,6 +64,7 @@ .It Tn "Avlab PCI 2S (2 port serial)" .It Tn "Boca Research Turbo Serial 654 (4 port serial)" .It Tn "Boca Research Turbo Serial 658 (8 port serial)" +.It Tn "Cronyx Omega-PCI (8 port serial)" .It Tn "Decision Computer Inc PCCOM PCI 2 Port (2 port serial)" .It Tn "Decision Computer Inc PCCOM PCI 4 Port (4 port serial)" .It Tn "Decision Computer Inc PCCOM PCI 8 Port (8 port serial)"
