IRC channel logs

<damo22>welcome back youpi

<etno>youpi: thanks, this is clearly what I would prefer to do. I distupgraded from 20230606 to debian-ports/sid. So my sources.list contains debian-ports for both packages and sources; this repo doesn't have source metadata at the usual location. I will search in the base files for the default deb-src entries.

<solid_black_>good morning

<etno>Probably something dumb I am doing, but ftpfs gives me a "Permission denied" when I do:

<etno>~$ settrans -a -g -c cdimage.debian.org /hurd/ftpfs cdimage.debian.org

<etno>~$ ls cdimage.debian.org/

<etno>ls: reading directory 'cdimage.debian.org/': Permission denied

<etno>In ftpfs, netfs_check_open_permissions() returns always ESUCCESS, and get_dirents() is never called :-/

<youpi>etno: https://www.debian.org/ports/hurd/hurd-install provides the information

<solid_black>are "uart", "com", and "serial" the same thing? or perhaps are "uart" and "com" different kinds of "serial"?

<youpi>solid_black: they are

<youpi>uart just usually designates the chip

<solid_black>(what chip? last time you said there a just a few wires and that's it?)

<youpi>you have a chip at both ends of the wire :)

<youpi>etno: ftpfs also takes the path within the ftp, see ftpfs --help

<youpi>but it seems that things don't work for cdimage indeed

<youpi>things do work for ftp.gnu.org

<youpi>probably there's an ftp protocol concern with cdimage

<etno>youpi: thanks for the confirmation (and for the deb-src pointer)

<biblio>solid_black: in riscv (one vendor) deivce tree they added - https://en.wikipedia.org/wiki/16550_UART

<solid_black>"It is frequently used to implement the serial port for IBM PC compatible personal computers"

<solid_black>so "uart" is used to implement "serial ports" for IBM PCs

<solid_black>hmm

<youpi>it's the chip, yes

<solid_black>oh do you mean there is a chip between the CPU and the wire?

<youpi>yes

<youpi>the cpu almost never talks directly with the ouside

<solid_black>I thought CPUs had, like, pins, and directly controlled voltage/current on them?

<youpi>almost none

<solid_black>does the chip also have its own instruction set, registers etc etc?

<youpi>I mean, yes it has, but not to the outside world

<youpi>and rather to another chip

<youpi>depends on the chips

<youpi>uart don't need to be complex

<youpi>but network cards for instance, very typically yes

<solid_black>and "UART" is the name of faily of chips?

<youpi>for serial ports yes

<youpi>like NIC is often used for network cards

<biblio>solid_black: https://github.com/eecsmap/riscvm/blob/master/qemu-riscv64-virt.dts device tree example - soc { --> uart@10000000 { compatible = "ns16550a"; ...

<solid_black>...that attach to a CPU (how? via a bus? is it a part of the board/SoC?) and speak the serial port protocol over a real wire?

<solid_black>where does the word "com" come from?

<youpi>it's attached through the ISA bus originally

<youpi>which was directly to the cpu

<etno>Most of the SoCs have the UART component built-in, but architecturally, this is still separate from the CPU

<youpi>nowadays that goes through the motherboard main chip

<youpi>but programmatically it's still seen as programmed through the ISA bus

<solid_black>biblio: I've seen some device trees; my issue is I lack some fundamental understanding of how hardware / electric engineering side of this all works

<youpi>that's what outb(0x3f7, 'a') does

<youpi>it sends the byte on the ISA bus at the 0x3f7 address

<youpi>where the uart lives

<solid_black>aha, so x86 inb/outb read/write to the ISA bus?

<youpi>yes

<youpi>for low addresses

<youpi>for higher addresses that's rather to the PCI bus

<youpi>(even if nowadays it's all handled by the motherboard main chip)

<solid_black>what happens if I write to serial/aurt/com, but there's nothing attached to the other side? does it just all go to /dev/null? is there a way to detect if there's anyone on the other side?

<youpi>null yes

<youpi>usually you detect whether there's some hardware by reading the value

<youpi>if it's 0xff probably nobody is there

<youpi>otherwise you can try to write to a well-known register, and see whether the value does get modified

<youpi>which means there's indeed a register

<youpi>and then you can hope that it's indeed the right hardware you're talking to

<youpi>yes, ISA is really not plug-and-play, you need to know what hardware is at what address

<anatoly>on riscv you just write/read to/from address in a mem to access uart

<youpi>0x3f8 is reserved for com0, 0x2f8 for com1, 0x3e8 for com2, etc.

<etno>tweaking the IRQ&ports numbers was a major sports in the 80s 🙂

<anatoly>pardon me being basic :-D

<youpi>that's why people introduced device trees

<youpi>to document where hardware is

<youpi>yes, it's mostly only x86 that has a dedicated bus for i/o

<youpi>other hardware just use the usual memory bus

<youpi>nowadays cards often provide PCI BARs that can be mapped to do so as well

<youpi>(and btw avoid being limited by the 16b address space of the i/o bus)

<rrq>some h/w occupies 2 slots; one for "control" and one for "data". depends on h/w.

<youpi>most hardware have several ports

<youpi>some hardware have a lot :)

<biblio>anatoly: as far I understand, it depends on which address vendor put it - in case of sifive/qemu-riscv64-virt 0x10000000 (uart@10000000)

<solid_black>I do understand that part (to some extent) -- that I have to parse the device tree, read the base address from there, and then read/write to memory to access UART (or other devices)

<youpi>that's the idea, yes

<solid_black>and with some luck, I can even find docs and/or examples on what "registers" there are at which offsets, and how to do things

<anatoly>biblio: yep, it's ahrdware specific, I think I saw that SBI can tell it

<youpi>solid_black: yes

<solid_black>but what I have very little understanding of, is what that writing to memory actually does

<solid_black>send some signal on some bus? raise some voltage somewhere? etc etc

<youpi>for uart, when you write a byte to 0x3f8, it tells the uart to send that byte over the write

<youpi>at another address, you have a register that actually maps to the control electrical pins of the uart (those along the usual 3 wires, to tell hardware control flow, modem status, etc.)

<solid_black>well yes, now that you have explained, I understand that outb() sends the byte over the ISA bus, and that there's an UART chip that receives that byte and actually sends it over the serial cable

<youpi>so that wholy depends on the hardware

<solid_black>"do outb(0x386)" is the part I'm unfamiliar with, but can reasonably find online

<youpi>it's a cpu instruction

<solid_black>yes yes

<youpi>but you can see that as *(unsigned char*) 0x3f8

<solid_black>but the rest of that, not only I am unfamiliar with, I have no idea where else to learn about

<youpi>it's basically the same, just in a different address space, and on riscv it's not separate

<youpi>then for the details you need to look up hardware documentation indeed

<solid_black>(I wasn't acking what outb is, I was saying that specific details of what to write at which address can be reasonably looked up)

<etno>solid_black, osdev wiki is probably a good place to find neat info about that

<solid_black>I know about osdev wiki, and indeed it has some explanations

<biblio>so far I understood from books. BIOS or internal design will map those chips in specific memory addresses. So, when you write something to those memory addresses it will be forwarded to the corresponding chip.

<rrq>whe you write to a uart, the data goes into a shift register that shifts out one bit at a time, to successively control the signal level on the wire

<rrq>it's "decorated" with start and stop bits, e.g. low start and high stop, which then is kept high until the next data's start bit(s)

<solid_black>is there an underlying reason why this is implemented as a separate chip, and the CPU cannot control the wire directly?

<youpi>flexibility

<rrq>and cost

<youpi>about cost, embedded devices put everything on the main cpu :)

<youpi>it's really about flexibility

<solid_black>yeah, how's making a separate chip cheaper?

<youpi>so you can build a PC with no serial port, or one, or ten

<rrq>yeah probably

<etno>and reuse the UART in other designs

<youpi>solid_black: perhaps he meant that with the flexibility you can build a cpu with no serial port, thus less costly, and then add what you actually need around

<youpi>solid_black: also, you have different UART levels of quality

<youpi>with different speed support, buffering, etc.

<solid_black>that's also I question I wanted to ask, can there not be a serial port at all, or is there always one?

<youpi>there can be none

<anatoly>solid_black: not making two chips as a package but as two separate entities by two separate companies

<youpi>solid_black: though for embedded like riscv, you basically always have one

<youpi>to at least debug when things go really wrong and the video cards cannot even be initialized

<solid_black>what happens if there's no UART, and you do outb(whatever)?

<youpi>nothing

<etno>It lands in the void

<anatoly>it just unmapped memory I guess

<anatoly>so I we looking at mach on riscv?

<solid_black>anatoly: biblio was porting mach to risc-v yes

<solid_black>and I'm doing the aarch64 port

<biblio>anatoly: current status - https://netuse.dynamicmalloc.com/cgit/gnumach-riscv.git/diff/riscv/README?id=6fca8abef7e6d7be1a9e6d93dd0f2b7fbc5b28e5

<solid_black>it works somewhat, but I need a better understanding of the hardware side to progress further

<anatoly>I'm not going to look at that because I have my riscv branch in local mahc gut :-P

<anatoly>*mach git repo

<biblio>anatoly: :) if you make some progress please feel free to share the code. so I can also added those in my repo.

<anatoly>nah, you're looking at the wrong person. I so far have a mismatch in type size: from what my cross-compile mig produces and what cross-compiled mach expects

<rrq>maybe "computer peripheral programming" is a good search term

<anatoly>:-)

<anatoly>A year ago or two I played and had nasic bare-metal binary running and compiled few basic things from mach using custom Makefile because I didn'

<anatoly>I didn't want to dive into autoconfig and stuff

<anatoly>This January I took different attempt to compile as much of mach core code and ended in mig generated stuff and this where I'm currently

<anatoly>I guess that's nothing :-D

<biblio>anatoly: I did autoconfig staffs already.

<anatoly>And I started looking into virtual memory, did few little apps to play with translation tables for SV32 mode

<anatoly>just to put my head around it

<biblio>anatoly: it would be great if you share your code somewhere. https://netuse.dynamicmalloc.com/cgit/gnumach-riscv.git/diff/riscv/riscv/boothdr.S?id=6fca8abef7e6d7be1a9e6d93dd0f2b7fbc5b28e5 I reached before /* Initialize page tables and relocate to virtual addresses */

<anatoly>hah, I ahve exatcly dsame lines in riscv/riscv/model_dep.c

<anatoly>*haha

<anatoly>around putchar for uart

<anatoly>I used some code from BSD, I think FreeBSD for SBI interface

<anatoly>Not sure if using code from FreeBSD ok or not

<anatoly>But it

<anatoly>it

<biblio>anatoly: few issues I am facing for riscv. 1. lack of documentation - (they already publish code themselves in linux kernel). 2. some of their memory management coding are linux specific. so it is not straight forward to copy them.

<biblio>anatoly: no, I like doing things by learning from books or reference.

<anatoly>it's trivial code and netbsd has exactly same with slightly diffrent naming

<biblio>anatoly: codes are from riscv code from linux partially as mentioned in README

<anatoly>I just wanted to test that I can access data from opensbi

<biblio>anatoly: i can run my code in qemu opensbi

<anatoly>I mean to use opensbi functionality like shutdown, etc

<anatoly>I copied code for this purpose, jsut to make sure I'm on the right path and doing something stupid

<biblio>anatoly: qemu-system-riscv64 -M virt -m 128M -nographic -bios YOUR_opensbi/build/platform/generic/firmware/fw_dynamic.bin -kernel gnumach should work after you build it.

<biblio>anatoly: ok

<anatoly>that stuff in _start_kernel is beyond my understanding, sorry

<anatoly>I can see some stuff I read and saw before but that's what I need to learn :-)

<biblio>anatoly: I also thought same. But it is quite easy. GNU LD documentation and "Linkers and Loaders" book will help. With basic memory - https://en.wikipedia.org/wiki/.bss (Advanced Programming in the Unix Environment for details.)

<anatoly>biblio: interesting, I build mig the same way, but I have size mismatch in one of time related types in mach currently

<anatoly>hm, I guess I'm missing some flag defined for mach

<anatoly>I have ldscript and .S file but they are mach simplier (to the extent of what I understand)

<biblio>anatoly: it would be nice to make code simpler for sure. let me know if you publish your code somehwere.

<anatoly>biblio: I know anything can be learned given infinite time (we're in the end no trying to breal rules of physics here, jsut moving bytes back and forth). I'm just staying of where I'm now :-)

<anatoly>*saying

<anatoly>Can push it, but it's just little hacks here and there :-D

<biblio>anatoly: "Linkers and loaders" book 250 pages. 5 pages each day = 50 days = 2 months max. (moreover, you dont need to read all pages) :)

<biblio>anatoly: sure. waiting.

<anatoly>I think I went through some manual for the linker to quickly understand what all of that syntax means and some specifics

<anatoly>That's too slow :-)) and I will forget what I've read a week ago if I'm not applying it, so it should be a process in parallel solving issues and learning tot he bottom of it

<biblio>anatoly: agree

<solid_black>biblio anatoly: we have all the autoconf and IPC sizing things figured out over here on aarch64

<solid_black>so you might want to talk to me about it :)

<biblio>solid_black: it would be great if you share you aarch64 code. is it in github ?

<solid_black>it is, let me find the link

<solid_black> https://github.com/bugaevc/gnumach/tree/wip-aarch64

<biblio>solid_black: ok

<anatoly>I fixed on of them by properly building mig but then the other one just doesn't make sense so far for me :-D

<biblio>solid_black: In i386 debian hurd. If I compile gnumach with default settings. I am getting "error: unknown type name 'mach_msg_type_name_t'" I guess it is for - old glibc or other lib. But if I ../configure --enable-apic --enable-kdb --disable-linux-groups I can build but after botting could not find disk.

<solid_black>please take a look at the device tree parser, https://github.com/bugaevc/gnumach/blob/wip-aarch64/device/dtb.h (& .c) -- it's supposed to be usable for you on risc-v too

<solid_black>(and tips/suggestions are very welcome)

<solid_black>biblio: compiling gnumach doesn't depend on glibc, so that cannot be it

<solid_black>perhaps it's just missing an include of the relevant header?

<biblio>solid_black: ok I will check again.

<solid_black>anatoly: what is that "other one"?

<biblio>solid_black: wow device tree parser. :)

<solid_black>it has to work before kernel heap is initialized, hence some design decisions

<anatoly>I really don't like that these service add following line into repository setup example "git init --initial-branch=main". Thanks for telling me how to call stuff

<anatoly>*services like github and gitlab

<anatoly>solid_black: I need to run build to show details, let me finish with pushing :-D

<biblio>solid_black: anatoly: example animation of boot process with device tree for risc-v https://embeddedinn.com/articles/tutorial/RISCV-Uncovering-the-Mysteries-of-Linux-Boot-on-RISC-V-QEMU-Machines/

<biblio>"THe QEMU ZSBL" part

<anatoly>biblio: here we go, my humble-mumble https://gitlab.com/anatolykazantsev/gnumach

<anatoly>solid_black: riscv-none-elf-gcc -fno-builtin -ffreestanding -march=rv32g -mabi=ilp32 -mcmodel=medany -I ./ -I riscv/include -I include -D KERNEL=1 -D MACH_KERNEL=1 -D NCPUS=1 -D CPU_L1_SHIFT=6 -D STAT_TIME=1 -c -o kern/mach_host.server.o kern/mach_host.server.c

<anatoly>kern/mach_host.server.c: In function '_Xhost_adjust_time':

<anatoly>kern/mach_host.server.c:1921:9: error: static assertion failed: "expected rpc_time_value_t to be size 4 * 2"

<solid_black>(you probably didn't mean to commit .clangd with the path to your ~)

<anatoly> 1921 | _Static_assert(sizeof(rpc_time_value_t) == 4 * 2, "expected rpc_time_value_t to be size 4 * 2");

<anatoly> | ^~~~~~~~~~~~~~

<anatoly>kern/mach_host.server.c: In function '_Xhost_get_time':

<anatoly>kern/mach_host.server.c:1988:9: error: static assertion failed: "expected rpc_time_value_t to be size 4 * 2"

<anatoly> 1988 | _Static_assert(sizeof(rpc_time_value_t) == 4 * 2, "expected rpc_time_value_t to be size 4 * 2");

<anatoly> | ^~~~~~~~~~~~~~

<anatoly>make: *** [<builtin>: kern/mach_host.server.o] Error 1

<anatoly>ah, yeah, I saw it but no secrets here I used vscodium :-D

<youpi>anatoly: which version of mig are you using?

<biblio>anatoly: thanks. I used dummy code from x86 to compile my code, but you implemented some of the necessary files. :)

<solid_black>anatoly: what's your rpc_long_integer_t?

<anatoly>youpi: MIG_COMMIT=e5c3fa44fb75b23dc7100202e52f3d4366447851

<solid_black>it is long long 🤔️

<solid_black>but where's yout machine_types.defs?

<youpi>anatoly: perhaps you need d9d2d5936e71e65e8f35ca79cae3f07c00db3515 too

<youpi>at least, you need to show us your configure output

<youpi>to make sure what compiler combination you are using

<anatoly>./configure --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/share/man --localstatedir=/var \ --target="riscv-none-elf" \ TARGET_CPPFLAGS="-march=rv32g -mabi=ilp32 -mcmodel=medany -I/tmp/include -D KERNEL=1 -D MACH_KERNEL=1 -D NCPUS=1 -D CPU_L1_SHIFT=6 -D STAT_TIME=1" \ TARGET_CC="riscv-none-elf-gcc" TARGET_CFLAGS="-fno-builtin"

<anatoly>this how I build mig

<solid_black>anatoly: no really, where are your machine_types.defs? where is rpc_long_integer_t defined for risc-v?

<anatoly>solid_black: pushed

<solid_black>also, aren't there both 32-bit and 64-bit versions of risc-v? are you supporting both?

<anatoly>I concentrated on 32bit

<solid_black>I understand, but is this meant to eventually support both?

<biblio>solid_black: it should work on both (with minimal changes) as far I understand from their doc.

<solid_black>anatoly: see, you just copied machine_types.defs from i386, and that wouldn't work, since it has, like, if defined(__x86_64__)

<biblio>solid_black: I focus on 64 as the hardware available from sifive or other vendors are 64-bit. riscv-32 specially designed for embedded systems (based on the doc.)

<anatoly>solid_black: yep, but I didn't try to prepare base to support both. It's basically out of man power to design things in the area I have zero experience, so ahrdcoded 32-bit to make things easier ofr me on my path

<solid_black>sure, I too have zero experience, and you can't do everything right upfront

<solid_black>just trying to understand your intentions, that's all

<anatoly>solid_black: but __x86_64__ supposed ot to be defined and maybe it's where my problem is, I could indefined it to test my assumption :-)

<solid_black>hm, wait, maybe it's something else

<solid_black>how does this work on i386, if rpc_long_integer_t is long long in C and int32_t in MIG?

<anatoly>solid_black: learning and a journey but not the end result :-)

<solid_black>the end result too, I sure want to have the Hurd running on ARM for real :)

<biblio>solid_black: same for me but in risc-v

<solid_black>well, yes, on i386 it's not defined as long long, which only makes sense

<anatoly>anatoly: yeah, sure, but I know my capabilities and limitations :-) so the goal is little: learn while poking unknown

<solid_black>anatoly: where did that long long come from in your version?

<biblio>solid_black: but i think - SMP support is the important thing pending for x86, arm, risc-v

<solid_black>SMP is not really pending for aarch64, I haven't been paying much attention to it, someone with a better understanding of the hardware would have to do it

<anatoly>solid_black: so you're asking why my long_integer_t is long long?

<solid_black>yes

<solid_black>it should be: typedef long long_integer_t; typedef long_integer_t rpc_long_integer_t;

<solid_black>if you're supporting USER32 (which there is little reason to), then under if defined(MACH_KERNEL) && defined(USER32), typedef int32_t rpc_long_integer_t;

<anatoly>solid_black: so integer_t and long_integer_t it will be of the same size?

<solid_black>on 32-bit, yes

<solid_black>on 64-bit, integer_t is 32-bit, long_interger_t is 64-bit

<solid_black>just like int/long in C

<anatoly>ah, ok, I was under impression it should be bigger from the relevant comment in machine/vm_types.h

<solid_black>you could make it 64-bit if you really want to

<solid_black>but in that case, make sure to make the MIG definition (in .defs) to match

<solid_black>your static assertion failure is from the C definition saying rpc_long_integer_t is 64-bit, and the MIG definiotion saying it's 32-bit

<anatoly>I was trying to chase it but my mental model of what it should be in the end was saying all is okay-ish, so couldn't find the root of the issue

<anatoly>Need to look into it again to make sure I have a picture in my head

<anatoly>it passed the assert

<anatoly>I must make sure I understand it

<anatoly>solid_black: thanks!

<solid_black>you're welcome :)

<solid_black>and please ask further questions if something is unclear

<anatoly>solid_black: for alpine-hurd I was able to build an image within a container without root privs

<solid_black>an image, as in a bootable fs image?

<anatoly>anatoly: haven't finished the code thus haven't pushed it yet

<solid_black>also I haven't pushed my latest work, have I :(

<anatoly>solid_black: yes, that's what I boot when I sent you a messahe about it

<anatoly>solid_black: I think so, but I rebased on top of latest from you for now

<solid_black>cool anyway

<solid_black>the next step would be to figure out building DDE; I had a WIP change for that but it didn't build

<solid_black>so, to investigate that build failure

<anatoly>Rightio, it is bedtime

<solid_black>is "com" (as in Mach device) a name of the specific serial port/connector?

<solid_black>and "uart" is a family of chips that implement it?

<solid_black>do uart chips implement other ports?

<rrq>afaik uarts serve to translate between parallel and serial data representation, and I suppose traditionally (on windows) the serial ports were referred to as "com" ports; I don't know anything about mach device naming scheme(s)

<solid_black>there's also /dev/ttyS0 and so on, on Linux

<solid_black>I don't have /dev/com0 on Linux though, so that could be Mach-specific?

<rrq>mmm probably. (though my friendly browser also pointed to cygwin :)

<rrq>you've seen this I suppose https://www.nongnu.org/thug/serial-howto.txt

<azert>solid_black: I think midi ports might be implemented by the same chip as a com port

<azert>At least when I play with midi instruments using a pic microcontroller, I use the uart and it works perfectly fine

<solid_black>rrq: I haven't seen that, but that doesn't seem to contain anything new either? if you want a console on "com0", sure, settrans /dev/com0 /hurd/term, and run a getty on it

<azert>Also in the past you would use the com device as a serial bus, to connect mouses for instance

<azert>On PC, midi uses the mpu-401 chip, but it’s basically an uart

<azert>Pc hardware is ridiculously complicated, in my opinion the driver was NOT flexibility but profit

<rrq>it seems hard to find something authoritative and/or specific about hurd device node naming

<rrq>but it appears /dev/com* is used for serial ports

<rrq>I guess the actual name isn't really too significant but rather by habit/custom

<youpi>azert: flexibility means profit

<youpi>since you can reuse parts that already exist, and thus cheap

<youpi>com just means communication, essentially

<youpi>that was used e.g. on msdos

<youpi>ttyS just means a tty on a serial port

<youpi>so different meaning

<youpi>but technically the same in the end

<youpi>using the com name is indeed somehow mach-specific, as in: not linux-specific

<youpi>but using com is a common thing

<azert>Trivia: In windows you still cannot name a file com

<youpi>it's just the user-visible name

<youpi>and uart is the chip, users don't know about it

<rrq>I also found it had been used with netbsd yonks ago (or still maybe?)

<solid_black>what I'm really trying to understand is should the UART/pl001 Mach driver on aarch64 expose itself as "com0" or something else ("uart0"? "ttyS0"? "pl001?")

<youpi>call it com0, yes

<azert>rrq: just noticed that netbsd “man com” have a BUGS section mentioning that it comes from DOS

<rrq>yes, but "com" for "communication" is also a good explanation future-wise

<solid_black>but "communication" can mean anything

<youpi>yes

<youpi>that's essentially why it wasn't taken for other OSes

<biblio>solid_black: in linux to enable serial output boot kernel parameter "console=tty0 console=ttyS0,9600n8". But in hurd "console=com0". If you name something else instead of com0 many configurations need to be adjusted for aarch64.

<youpi>but better be coherent for now

<youpi>and documentation

<youpi>we already have plenty of diverging documentations

<youpi>better not contribute to the divergence

<rrq>being based on a device tree defintion it won;t suffer randomness of numbering even if comN is used also for more than uart ports, like parallel ports.

<rrq>(unless the drivers get installed in parallel I guess)

<youpi>parallel ports are called lpr in mach

<rrq>ok

<rrq>is there a naming spec?

<youpi>what do you mean by "spec" ?

<solid_black>i386/i386at/conf.c

<rrq>well, something that would document those choices

<youpi>you mean the rationale ?

<youpi>there's probably not much more than the fact that at the time people would usually call them that way, notably because of ms-dos

<rrq>that's fine; though history only sticks to the old ones :)

<rrq>hmm I just found netbsd's MAKENOD ... uses a few variant "..com" names for COM ports; eg ps://man.netbsd.org/NetBSD-9.3/MAKEDEV.8

<rrq>not totally relevant here, but a good piece of documentation to have

<rrq>(oops my copy-paste lost the "htt" bit)

<Guest83>Hi Hurd

<biblio>Finally, I was able to build image and run hurd x86_64 version. able to login. (the documentation is not straight forward but it worked.)

<damo22>ok

<damo22>is there a debian disk image for that?

<biblio>damo22: no, it is all from source. based on - https://github.com/flavioc/cross-hurd

<biblio>damo22: i had to add some minor edit to make it work for 64-bit

<biblio>damo22: I built gnumach using ../configure --enable-ncpus=8 --enable-apic --enable-kdb --disable-linux-groups, but I could not boot (disk not found). which command you are using in qemu to boot in your local.

<biblio>damo22: I write a note how to build 64-bit from cross-hurd

<damo22> new libc0.3:hurd-amd64 package post-removal script subprocess was killed by sinal (Killed)

<damo22>how can i upgrade my hurd64

<damo22>biblio: smp is not working on i386 let alone x86_64

<biblio>damo22: yes, I read SMP doc in intel doc. at least go basic of it. I will check if I can help you there.

<damo22>biblio: i have not tried 64 bit hurd much yet

<biblio>damo22: Sorry for the confusing. I tested hurd-64 bit that is separate issue.

<damo22>ok

<biblio>damo22: i tested you SMP dev branch in i386. And boot with -smp 2 after botting it could not find (disk). So, I was wondering which parameters you are using to boot (when you build gnumah using ../configure --enable-ncpus=8 --enable-apic --enable-kdb --disable-linux-groups) and your grub config.

<damo22>qemu-system-i386 -M q35,accel=kvm -smp 8 -m 4096 -net user,hostfwd=tcp::8888-:22 -net nic -display curses -hda /path/to/disk/or/image

<biblio>damo2:: yes -hda i was looking. you explained before but I did not get it.

<biblio>damo22: ok thanks I will test with these parameters

<damo22>i think smp 2 might have problems

<damo22>because it isolates to one cpu in each set

<damo22>youre better off with -smp 1 or 4

<biblio>damo22: ok noted

<damo22>lol i think i hosed my 64 bit install

<damo22>is there a disk image available for 64 bit?

<biblio>damo22: I could not find so far, but if you want I can build a fresh image and upload.

<biblio>damo22: or you can just build using corss-hurd also.

<damo22> https://people.debian.org/~sthibault/hurd-i386/disk-amd64.img.gz

<biblio>damo22: ok thanks.

<damo22>argh no git

<solid_black>why is there a need for an interrupt controller, what does it do that the CPU itself cannot?

<solid_black>(I think I understand what it does; but I don't understand why CPU itself doesn't implement that)

<youpi>the cpu doesn't have a line per irq

<youpi>so it's the controller that gets all the irq lines, and sends the irq number to the cpu for interrupting it

<youpi>again, flexibility :)

<solid_black>ah, so the interrupt controller has separates "lines" ( = wires? pins?) for each irq, and it transforms the number of the line that fired into a binary number that it sends to the cpu via some bus?

<youpi>wires, yes

<youpi>yes

<youpi>that's why you need to configure it, to tell it which number it should use for which line

<damo22>and mapping these is a nightmare with acpi

<youpi>since you might have different interrupt controllers, you don't want a mixup

<damo22>linux avoids this problem mostly now by using MSI

<damo22>a programmable way to define the interrupt as a message i think

<youpi>that avoids the pins yes but you still have a controller that receives the messages and notifies the cpu

<damo22>i dont know enough details but if we used MSI/MSI-X would it be possible to remove libacpica from being required?

<damo22>i mean, to bypass the interrupt pin mappings

<damo22>its probably lower latency if we keep it though

<damo22>youpi: does rsync know about xattr on ext2?

<youpi>man rsync seems to say it knows about xattr

<damo22>$ rsync -avX testit /part3/

<damo22>rsync: extended attributes are not supported on this client

<biblio>damo22: Stopped at Debugger+0x13: int. At least I can boot it for debugging now.

<solid_black>but why doesn't the CPU just have its own pins for each interrupt directly? is it just that (for flexibility reasons) you don't want to commit to a fixed number of irqs when desiging the CPU model, whereas you do commit to a number for interrupt controllers, but it's ok because you can attach different interrupt controller models to the same CPU model?

<damo22>yes solid_black

<solid_black>like, I imagine a CPU is this super complex thing that does prefetching and caching and instruction decoding and speculative execution and whatnot; why does it need an external and relatively simple external chip just to convert input on pins into numeric form?

<damo22>legacy mess

<anatoly>I was skimming through pcb, tss and firends code and I guess it's pretty irrelevant for arm/riscv

<solid_black>but I imagine this is also the case for newer architectures? don't risc-v CPUs need an interrupt controller too?

<solid_black>anatoly: pcb is surely relevant for aarch64, look at aarch64/aarch64/pcb.[hc] in my branch

<solid_black>tss, I've no idea what that is, so maybe no

<youpi>about external irq controllers: it's not legacy mess, it's putting out of the cpu what can be

<youpi>to make it simpler, precisely

<youpi>no need for a vast series of pins just for interrupts you don't even know how many you will need

<youpi>also, you're only seeing one example

<solid_black>so it is precisely about not comming to a number of interrupt pins?

<solid_black>or is there more to it?

<youpi>there is a *vast* number of such "small chips" that we don't really want to have to embed in the cpu

<anatoly>I mean PCB from mach point of view is essential of course

<youpi>the keyboard controller, the timer, the pci controller, arp controller, whatnot

<youpi>solid_black: the pins by themselves take room

<youpi>better not put that on the cpu

<youpi>but, yes, for a start, *not* committing to a given number is an important thing

<youpi>x86 did commit to 256 interrupts, but that's just software, and it doesn't actually take much room

<solid_black>but then there is some pretty standard interrupt controller model that everyone just uses?

<youpi>there used to be some, yes

<youpi>now they're mostly embedded in the motherboard main chip

<youpi>which is fine since it's built with the motherboard which does embed the hardware that needs the irqs

<solid_black>or is this more about factorization of concerns, just to keep things separated when tehy can be, like we all do in software?

<anatoly>^^^ solid_black dreams come true verything on one crystal

<youpi>solid_black: it's also that

<youpi>note: there's never only one main reason for something, it's always a network of compromises

<solid_black>anatoly: goes without saying, I'm not arguing that things *should* be done some way, I don't have nearly enough understanding of the hardware involved (almost zero, as you can see from what I'm asking) to make such claims

<youpi>so if you ask for one simple answer, you'll get a not-so-good answer

<anatoly>dot hey call it a life? :-)

<youpi>and the real answer would take a long time to explain

<solid_black>I'm only trying to understand the reasoning behind the design(s)

<youpi>that takes huge books to fully comprehend

<youpi>since there are decades of engineering over that

<damo22>i82093

<solid_black>speaking of books, do you know if there's any good guide or doc or book about this, that would explain how things fit together *conceptually*? like, not a list of bytes that you need to "outb", but an explanation of how things work & fit together

<anatoly>solid_black: I should've add a smile at the end of my sentence :-)

<solid_black>ok :)

<etno>Hi ! I am building packages on a hardware i386 hurd system, and rumpdisk is consuming most of the CPU. Just wondering if there is something wrong with my setup or it is expected ?

<damo22>etno: we need smp

<youpi>at the time, I had read https://www.amazon.fr/Bible-PC-Collectif/dp/2742905448/ref=sr_1_1

<youpi>that's the french version, I guess there's an english version

<youpi>etno: possibly dma is not set up

<youpi>and thus pio does indeed take a lot of cpu

<youpi>damo22: if it's the driver that eats cpu, it's most probably not a problem of parallellism

<youpi>drivers are not supposed to eat that much cpu time

<etno>youpi, it really looks like PIO, yes. Is DMA something that is supposed to be available with rumpdisk ? Or it has to be implemented ?

<youpi>and access to hardware is most often not parallel anyway

<youpi>it is implemented and working on my box

<etno>ok, let me look at the boot logs then, thanks !

<youpi>otherwise performance is really bad

<youpi>make sure to have the latest known version, I remember fixing something that was preventing dma

<youpi>ergl it's not released

<youpi>0~20211031+repack-4

<youpi>in the debian source tree

<youpi>patches/vm_allocate_contiguous_align:

<etno>Well, what gives me a serious hint is that ext2fs is way below in CPU usage, so it doesn't make sense that rumpdisk uses that much

<youpi>problem of allocation alignment

<etno>oh, then I just need to rebuild, no problem

<etno>(of course, if you can update it ..... :-) )

<youpi>time doesn't magically make itself unfortunately

<damo22>can symlinks have xattrs?

<damo22>probably not right

<anatoly>youpi: you need smp ;-)

<etno>sure, no worries, youpi

<damo22>youpi doesnt run in qemu

<damo22>halp

<damo22>:P

<anatoly>Right, it's tomorrow now so time to dream :-) see ya!

<youpi>damo22: I wouldn't be surprised that they can

<youpi>they're almost like normal files

<youpi>they even have content

<damo22>i think symlinks shorter than a certain size are stored differently as a metadata property

<damo22>anyway, i was looking into rsyncing a hurd install

<damo22>but that wont work yet

<damo22>because translator entries are not preserved

<solid_black>that would lose translator records, unless it syncs xattrs indeed

<solid_black>yes

<youpi>files shorter than that size can be recoded in metadata too iirc :)

<damo22>i am working on it

<damo22>rsync

<youpi>translator records are not in xattrs yet

<damo22>eh?

<solid_black>not in the disk format, but in the api, they are

<youpi>still pending somebody to actually check a migration plan

<solid_black>gnu.translator

<youpi>solid_black: yes but it's not used by default yet

<solid_black>huh?

<youpi>just like all kind of nice hurd features, still missing somebody to actually make the last step to integrate into normal processes

<damo22>it has to be, how are translator entries stored?

<youpi>which usually involved fixing bugs

<youpi>damo22: in a special field

<youpi>that is not an xattr

<damo22>oh

<youpi>see the entry about it in the contributing wiki page

<solid_black>translator records on ext2fs on-disk format are stored in the "OS specific" field yes, with an experimental option to store them in xattrs that's not on by default

<solid_black>but in the API, as in getxattr(), they are visible as gnu.translator

<youpi>just missing somebody to fix the last remaining issues

<solid_black>no matter how they are stored, or synthesized on the fly, whatever

<solid_black>see glibc:hurd/xattr.c

<damo22>if we use a different filesystem for / how will that work

<solid_black>as long as rsync uses the API and does not read the on-disk format directly (and itself runs on the Hurd), it should see translator records as xattrs

<youpi>damo22: the fs just needs to support xattr

<youpi>solid_black: ? xattr /servers/socket/2 doesn't print anything

<damo22>ok

<solid_black>ACTION checks

<damo22>xattr -l

<damo22>still nothing

<youpi>and anyway we do want to move to xattr

<youpi>on-disk

<youpi>so that e.g. genext2fs works, we drop special-casing in e2fsprogs etc.

<youpi>also cross-building a working hurd image from another os

<damo22>yes that is annoying now

<damo22>or rsyncing a hurd install to another disk