[HelenOS-devel] Minutes of HelenOS meeting 2024-09-12 + HelenOS camp 2024 report

2024-09-13 Thread Jiri Svoboda
Minutes of HelenOS meeting 2024-09-12
=

Attendees:
  JJ - Jakub Jermář
  JZ - Jiří Zárevúcky
  JS - Jiří Svoboda
Not present:
  MD - Martin Ďěcký
  MC - Miroslav Cimerman

Summary of HelenOS Camp 2024

HelenOS camp 2024 took place in a cottage in the municipality of Vír during
the days of August 17th-24th. It was attended by JJ, JS, JZ, MD + spouses 
and children. It was both productive and fun. Apart from coding we've also
made a number of trips/hikes, there was barbeque and people also enjoyed the
pool (despite the rather cold water).

Progress reports from the camp and from Aug/Sep can be found in the progress
update section.

Progress update
---
MD: (not present in the online meeting)
    - during the camp Martin enabled www.helenos.org with HTTPS, so now it
uses https:// instead of http://. Exception: HelenOS files can be downloaded
via HTTP not to break 'download'/'pkg'
    - Martin was also looking into improving effect support in libtrackmod

MC: (not present in the online meeting, sent a report)
    - vbd: free disk service name on disk remove
    - ata_channel_destroy(): unlock channel mutex after error
    - software RAID (thesis work)
  - working RAID 0, 1, 4 (but cannot work in degraded state nor
resilver)
  - saves metadata to disks and can import an exported pool
    - further plans:
  - RAID 5, possibly 6.
  - work in degraded state, resilver, hot spare
  - interoperability with some existing RAID solution?
JJ:
    - investigated why ARM/integratorCP does not work in Qemu - in the
meantime it was fixed in Qemu
    - ipc2 - completed rebase to current master
    - encountered problems with changes to condition variable API
 (it was not possible to sleep interruptibly)
    - some ipc2 unit tests were failing after rebase due to locking
changes
    - debate with JZr regarding absolute timeouts - problem on multi-CPU
system,
  each CPU has a different clock
    - need to think about how to implement memory sharing
    - need to distinguish client/vs. server operations on queue
    JS: can the owner of the memory lend it to a different task and
then revoke it? Would be useful for direct
    - after the camp waited for Qemu 9.1.0 (which contains the fix) comes
out
    - committed Qemu version bump
mutexu

JZ:
    - terminal resizing and scrolling
    - reallocarray
 - fixed bug in 32-bit build

JS:
    - added File/New and File/Open to text editor - important when running
from start menu
    - prevent failure when deleting a partition that is not mounted
    - config file persistence
   - initial configuration in /cfg is copied to /w/cfg when starting
live image or installing to disk
   - persistent config of taskbar (start menu)
    - simplify SIF interface (save/load instead of transactions)
    - change SIF storage format to be more XML-like
    - add UI window resize callback
    - persistent display (seat) config
    - persistent taskmon (corecfg) config
    - persistent volume configuration

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS online meeting today @ 21:30 GMT+0200

2024-09-12 Thread Jiri Svoboda
Hi,



just a quick reminder, HelenOS online meeting is happening tonight at 21:30
CEST. Looking forward to seeing you there!




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of HelenOS online meeting 2024-07-11

2024-07-12 Thread Jiri Svoboda
Minutes of HelenOS online meeting 2024-07-11


Attendees:
  MC - Miroslav Cimerman
  JS - Jiří Svoboda

Scribe:
  JS

Round table
---

Miroslav Cimerman

 - outlined his plans for his software RAID project
 - has created a GitLab repo for his project, but nothing committed so far
 - will send a link to the mailing list when there's something
 - JS: outline of how a server is typically configured in HelenOS these days
(protocol library, libsif..., note: plan to simplity libsif)
 - Is file_bd a good source of inspiration?
    - JS: yes, and vbd is perhaps even more similar to the software RAID
server

JS
  - hide cursor in text editor when menu/menu bar is activated
  - switch virtual consoles using Alt-Fn or Shift-Fn
    - allows the use of e.g. F10 to activate menu in console
  - reviewed and merged fixes by MaaSTaaR
    - fix build with defailed kernel logging enabled
    - determine initial ramdisk by name instead of being the last boot
module
  - fix display server not to deliver button down event to window below
popup window
 - incorrectly clicked on controls in main window
 - found by MaaSTaaR
  - reviewed MaaSTaaR's PR for minimizing active window by clicking its
window button on the taskbar
 - found issues
  - PC floppy disk driver
 - works in Qemu, uses ISA DMA
 - only supports a single drive, disk must be 3.5" DS/HD 1.44M
 - does not detect drive/disk presence, does not make use of interrupts
 - no motor of timer
 - mount automation disabled
 - MC: Where do you get the information needed to write device drivers?
    JS: industry standards, chip manuals (google them), OSDevWiki,
Wikipedia, SysMan can be useful to find out what you are looking for. Links
to all the docs we use can be found here: http://www.helenos.org/wiki/
DeveloperDocs I also try to reference the documents in the driver source 
itself.

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Passing window's state to the other UI widgets

2024-06-29 Thread Jiri Svoboda

Hi Mohammed,




a mouse press event should not be delivered to the UI control at all in the
described case. Btw. I've found a good test case is to run UI Demo, open the
'File' menu and click on the right side of the disabled entry, which is just
above the 'Cancel' button.




What we have here is a popup window that is over the focused window. The 
press event gets delivered both to the popup window and to the focused
window below. That is wrong.


The responsible function is ds_seat_post_pos_event() in the display server.
I have rewritten the function so now it hopefully works better. The problem
described above is fixed now. Mouse move and release events are still
delivered to the focused window, so dragging (e.g. scrollbar, window resize)
still work properly.




There is a generic solution not requiring to modify each control.




> So, I'm asking, is it OK to change the creation function of these widgets
in a way that it receives the window's state?

> The widgets that will be affected are: tabset, radiobutton, pushbutton, 
checkbox and slider.

There is a reason why these controls don't take a window as a parameter (at
the beginning of the UI library no controls did). When you create a window,
you also create its title bar. The title bar contains buttons. So you need
to create these buttons while the window still isn't fully constructed. If a
button required a window as a parameter, how do you create it if you still
didn't finish creating the window? Sure you could pass it a partially-
constructed window, but that's not very nice, you would need to be very 
careful not to do something with the window that still cannot be done at 
that point ... bleagh.




Cheers,

Jiri




-- Původní e-mail --
Od: Mohammed Q. Hussian 
Komu: HelenOS development mailing list 
Datum: 27. 6. 2024 18:38:17
Předmět: [HelenOS-devel] Passing window's state to the other UI widgets
"

Hello All,




When a window has a menubar and one of the menu entries is clicked by the 
user, the widget which resides under this entry will also be clicked also.
I've fixed this for some widgets (list, scrollbar and entry), the changes 
can be found here (https://github.com/MaaSTaaR/helenos/tree/ui-ddmenu-
overlap(https://github.com/MaaSTaaR/helenos/tree/ui-ddmenu-overlap)).




The fix is too simple, it depends on the window's state which should be 
passed to the widget that we would like to prevent it from handling the 
position event when the menubar is active. The problem with some widgets (e.
g. tabset) is that the window's state will not be passed to it when the 
creation function is called. So, I'm asking, is it OK to change the creation
function of these widgets in a way that it receives the window's state? The
widgets that will be affected are: tabset, radiobutton, pushbutton, checkbox
and slider.




Regards,

MQH


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] HelenOS a lot faster on 1 core?

2024-06-27 Thread Jiri Svoboda

Hi Mohammed,




it looks like something specific to VirtualBox. I tried ping_pong benchmark
and I get ~48k with 1 CPU and ~8k with 2 or more CPUs. In Qemu I get 56k 
with 1 CPU, 68k with 2 or 4 CPUs.




Regards,

Jiri




-- Původní e-mail --
Od: Mohammed Q. Hussian 
Komu: HelenOS development mailing list 
Datum: 26. 6. 2024 22:13:19
Předmět: [HelenOS-devel] HelenOS a lot faster on 1 core?
"

Hello All,




Not sure if this is the right place to ask, please let me know if it isn't.
I ran HelenOS on VirtualBox, one time with just one core and the second with
four cores and I noticed a big performance degradation in the latter case.
Is my environment the reason? Or is HelenOS itself slow in multi-core
machines?


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] The position of "initrd.img" in grub.cfg

2024-06-25 Thread Jiri Svoboda

Hi,




historically (before loader or kernel.dbg existed) the kernel 'modules' had
no names. Remember that HelenOS can be booted via different methods on
different platforms. On non-PC platforms a self extracting archive was used
and this did not store the module names. So the order was used to determine
which module is RD and all the other were init tasks. Given that now we 
detect loader and debug symbols by module name I don't see a problem doing
the same for the RAM disk.




-Jiri



-- Původní e-mail --
Od: Jiří Zárevúcky 
Komu: HelenOS development mailing list 
Datum: 25. 6. 2024 19:56:11
Předmět: Re: [HelenOS-devel] The position of "initrd.img" in grub.cfg
"

Hi! I'm not entirely sure but I think it might just be a historical relict.





-- jzr




On Tue, Jun 25, 2024, 7:25 PM Mohammed Q. Hussian mailto:maast...@gmail.com)> wrote:

"

Hello All,




I would like to ask, what's the reason that initrd.img should be the last 
entry in grub's modules list. I mean, for whatever reason this order is 
changed by the user, HelenOS will not be loaded.




I've made a small modification in "kinit.c" and tested it by changing the 
order of initrd.img and everything seems to work fine, the system is loaded
and the filesystem is there, I think this will be better for the stability
but I'm not sure about the reason of the decision (of making it necessary 
for initrd to be the last). The minor modification is on my repository (
https://github.com/MaaSTaaR/helenos(https://github.com/MaaSTaaR/helenos)),
please let me know if it's OK to create a pull request.


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz(mailto:HelenOS-devel@lists.modry.cz)
http://lists.modry.cz/listinfo/helenos-devel
(http://lists.modry.cz/listinfo/helenos-devel)
"


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS online meeting 2024-06-21

2024-06-21 Thread Jiri Svoboda
Minutes of the HelenOS online meeting 2024-06-21


Attendees:
  - JJ .. Jakub Jermář
  - JS .. Jiří Svoboda

Round table
---
JJ:
  - started to investigate tasks crashing on 486 build (ticket #871)
  - negotiated date of HelenOS camp

JS:
  - Split ata_bd into libata (generic ATA code) and isa-ide driver (ISA-
specific stuff)
  - Added PCI-IDE driver, added support for DMA - much faster in Qemu than
PIO (PIO: 150 kB/s, DMA: 2.5 - 40 MB/s), implemented interrupt sharing
  - Fix IPv6 address parsing - most addresses were parsed incorrectly
    - was testing in a network with actual IPv6 internet connectivity
    - still no luck talking to outside world - no mechanism to auto-
configure global-scope IPv6 address in Qemu and I don't know what address 
Qemu assigned to the VM
  - Fixed #871 - the dynamic linker processed the relocation table in the
executable first. If a library defines a public global variable, a non-PIC
executable that links with the library will contain a definition in .bss 
too. It will be initialized with a COPY relocation that copies the value 
from the library. All references to the variable will be relocated to the 
executable's instance. If the variable is initialized using a *relocation*,
the COPY relocation from the main executable must be performed *after* the
variable is initialized via the relocation in in that library's dynamic 
relocation table.

 - Fixed missing NULL terminator in sys_dirs array in sysinst
   - Installer working!
 - Reviewed and merged GPT GUID encoding fix by Miroslav Cimerman
    - in GPT GUIDs are encoded in a MS-specific mixed endian encoding (not
standard RFC big-endian encoding)
 - Fixed volume label / rootdir creation in mkfat for FAT32
   - volume label was not being set correctly

 - HelenOS in the media: independent articles (i.e. not written by us)
posted about 0.14.1 release in
   - https://www.lupa.cz/aktuality/cesky-operacni-system-helenos-vysel-v-
nove-verzi-nove-ma-nabidku-start/
   - https://www.abclinuxu.cz/zpravicky/helenos-0.14.1
  - It looks like there might be some interest in getting updates about new
HelenOS releases in Czech language
  - (Already seen in the previous release) it looks like there might be some
interest in Czech translation of HelenOS

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] HelenOS Camp 2024

2024-06-19 Thread Jiri Svoboda

Hi Jakub,




for me there will be +3 extra, though they will probably not stay for the 
entire duration.




Thanks,

Jiri

-- Původní e-mail --
Od: Jakub Jermář 
Komu: helenos-devel@lists.modry.cz
Datum: 19. 6. 2024 10:55:37
Předmět: Re: [HelenOS-devel] HelenOS Camp 2024
"Hi Jiri,

yes, this is the best week. Now we need to find a suitable accommodation.

We need to collect the number of extra participants for that.

For me it's either +2 or +3.

Cheers,
Jakub

On 6/19/24 10:50 AM, Jiri Svoboda wrote:
> Hi guys,
>
> can we finalize the dates so that I can plan the rest of my vacation?
>
> So do we agree on:
> Week 8 (17.8.-23.8.) AAA
> ?
> Thanks,
> Jiri
> -- Původní e-mail --
> Od: Martin Decky 
> Komu: helenos-devel@lists.modry.cz
> Datum: 12. 6. 2024 2:05:40
> Předmět: Re: [HelenOS-devel] HelenOS Camp 2024
>
>
> Dear all,
>
> > I was reminded of this so let's see what the time possibilities are.
> > Please indicate your availability during the summer ('X' for not
> > available, 'A' for available, '?' undecided).
>
> Here is my availability within the already smaller intersection of
> Jakub
> and Jiri S.:
>
> Week 3 (13.7.-19.7.) XXX
> Week 4 (20.7.-26.7.) XXA
>
> Week 8 (17.8.-23.8.) AAA
>
>
> This leads to the longest common span of August 17th to 23rd (or
> perhaps
> 22nd, i.e. 7 or 6 days). The other intersections are probably not very
> viable (3 or 4 days only).
>
>
> M.D.
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] HelenOS Camp 2024

2024-06-19 Thread Jiri Svoboda

Hi guys,




can we finalize the dates so that I can plan the rest of my vacation?




So do we agree on:


Week 8 (17.8.-23.8.) AAA


?

Thanks,

Jiri

-- Původní e-mail --
Od: Martin Decky 
Komu: helenos-devel@lists.modry.cz
Datum: 12. 6. 2024 2:05:40
Předmět: Re: [HelenOS-devel] HelenOS Camp 2024
"Dear all,

> I was reminded of this so let's see what the time possibilities are.
> Please indicate your availability during the summer ('X' for not
> available, 'A' for available, '?' undecided).

Here is my availability within the already smaller intersection of Jakub 
and Jiri S.:

Week 3 (13.7.-19.7.) XXX
Week 4 (20.7.-26.7.) XXA

Week 8 (17.8.-23.8.) AAA


This leads to the longest common span of August 17th to 23rd (or perhaps 
22nd, i.e. 7 or 6 days). The other intersections are probably not very
viable (3 or 4 days only).


M.D.

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] GPT partition type UUID

2024-06-13 Thread Jiri Svoboda

Hi Miroslav,




looks good. I wouldn't think the encode_xx_ee() functions are strictly
necessary, but if you'd like to have it this way, fine. I'd prefer if you 
didn't mark them as 'inline' as a matter of style, as it's superfluous - the
compiler is smart enough to figure that out for itself. Otherwise LGTM.




Cheers,

Jiri

-- Původní e-mail --
Od: Miroslav Cimerman 
Komu: HelenOS development mailing list 
Datum: 12. 6. 2024 23:28:17
Předmět: Re: [HelenOS-devel] GPT partition type UUID
"Hi Jiri,

I force pushed the changes on the current PR. What do you think?

--
mc


Jiri Svoboda  wrote:

> Hi Miroslav,
>
> > Do you mean something like:
> >
> > #define _UUID_NODE_LEN 6
> >
> > typedef struct {
> > uint32_t time_low;
> > uint16_t time_mid;
> > uint16_t time_hi_and_version;
> > uint8_t clock_seq_hi_and_reserved;
> > uint8_t clock_seq_low;
> > uint8_t node[_UUID_NODE_LEN];
> > } uuid_t;
>
> Yeah, something like that would work. Alternatively, you could also
represent node as uint16_t node_hi + uint32_t node_lo.
>
>
>
> Cheers,
>
> Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] GPT partition type UUID

2024-06-13 Thread Jiri Svoboda

Hi Miroslav,




thanks. I noticed the first one (just didn't push the changes), but missed
the second one. Now fixed in HelenOS/master.




-Jiri

-- Původní e-mail --
Od: Miroslav Cimerman 
Komu: HelenOS development mailing list 
Datum: 13. 6. 2024 1:17:02
Předmět: Re: [HelenOS-devel] GPT partition type UUID
"Hi Jiří,

I found out that after 645d38325f770af3d73b15f6b1c95d0c2f9de91b
you cannot create or read GPT disk labels. Some assertions fail
in pci-ide.c, the diff bellow fixes it (probably just typos).

There was no conflict with my changes, so I pulled upstream and
then committed the new changes, and just now I found out that it
is not possible to create GPT labels.

--
mc


diff --git a/uspace/drv/block/pci-ide/pci-ide.c b/uspace/drv/block/pci-ide/
pci-ide.c
index cc1a5f96c..80f3c5242 100644
--- a/uspace/drv/block/pci-ide/pci-ide.c
+++ b/uspace/drv/block/pci-ide/pci-ide.c
@@ -555,7 +555,7 @@ static void pci_ide_dma_chan_setup(void *arg, void *buf,
size_t buf_size,
chan->cur_buf_size = buf_size;

if (dir == ata_dma_write) {
- assert(buf_size < chan->dma_buf_size);
+ assert(buf_size <= chan->dma_buf_size);
memcpy(chan->dma_buf, buf, buf_size);
}

@@ -591,7 +591,7 @@ static void pci_ide_dma_chan_teardown(void *arg)
pio_write_8(bmicx, val);

if (chan->cur_dir == ata_dma_read) {
- assert(chan->cur_buf_size < chan->dma_buf_size);
+ assert(chan->cur_buf_size <= chan->dma_buf_size);
memcpy(chan->cur_buf, chan->dma_buf, chan->cur_buf_size);
}
}



Miroslav Cimerman  wrote:

>
>
> Hi Jiri,
>
> I force pushed the changes on the current PR. What do you think?
>
> --
> mc
>
>
> Jiri Svoboda jirik.svob...@seznam.cz wrote:
>
> > Hi Miroslav,
> >
> > > Do you mean something like:
> > >
> > > #define _UUID_NODE_LEN 6
> > >
> > > typedef struct {
> > > uint32_t time_low;
> > > uint16_t time_mid;
> > > uint16_t time_hi_and_version;
> > > uint8_t clock_seq_hi_and_reserved;
> > > uint8_t clock_seq_low;
> > > uint8_t node[_UUID_NODE_LEN];
> > > } uuid_t;
> >
> > Yeah, something like that would work. Alternatively, you could also 
represent node as uint16_t node_hi + uint32_t node_lo.
> >
> > Cheers,
> >
> > Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Let's move HelenOS meeting 2024-06-13 -> 2024-06-20

2024-06-12 Thread Jiri Svoboda

Hi all,




hope you don't mind if we postpone this month's meeting by a week to
Thursday 20th. This week I really don't have the capacity.




Thanks,

Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] GPT partition type UUID

2024-06-12 Thread Jiri Svoboda
Hi Miroslav,
"Do you mean something like:

#define _UUID_NODE_LEN 6

typedef struct {
uint32_t time_low;
uint16_t time_mid;
uint16_t time_hi_and_version;
uint8_t clock_seq_hi_and_reserved;
uint8_t clock_seq_low;
uint8_t node[_UUID_NODE_LEN];
} uuid_t;"
Yeah, something like that would work. Alternatively, you could also
represent node as uint16_t node_hi + uint32_t node_lo.




Cheers,

Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] GPT partition type UUID

2024-06-12 Thread Jiri Svoboda

Hi Miroslav,




good catch. It looks like GPT uses a weird Microsoft-specific encoding of 
GUID/UUID, whereas we use the encoding per RFC 4122. The other case where we
call uuid_encode() is in ext4 superblock, where it is appropriate since ext4
encodes UUIDs according to RFC 4122 (in network byte order).





I never thought alternate encodings would exist. In light of this, it might
make more sense for the internal representation to be actually structured,
at least for the first three dash-delimited fields (and maybe for all of 
them).


Your changes look mostly OK, although I am not a big fan of the helper
function (which couldn't exist anyway if we changed the internal
representation to structured).  Some of the inline comments incorrectly
start with a double asterisk, e.g. /** time_low */ even though they are not
documentation comments.




Cheers,

Jiri




-- Původní e-mail --
Od: Miroslav Cimerman 
Komu: helenos-devel@lists.modry.cz
Datum: 10. 6. 2024 18:25:01
Předmět: [HelenOS-devel] GPT partition type UUID
"Hi,
 
""I found that when creating GPT partitions, the partition
type UUID is encoded so that it is not possible to know
the partition type when looking at it outside of HelenOS.

I opened a PR on Github that fixes this issue.

Example:

qemu-img create testdisk.img 100M

qemu-system-x86_64 -enable-kvm -boot d -cdrom image.iso \
-drive file=testdisk.img,format=raw,media=disk

# in this example inside HelenOS I created 3 partitions:
# ExFAT, Ext4, FAT

Before my PR (fdisk -l ./testdisk.img output):

Disk ./testdisk.img: 100 MiB, 104857600 bytes, 204800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 80CAD31B-F30A-3449-8866-9656101F2153

Device Start End Sectors Size Type
./testdisk.img1 128 39295 39168 19.1M unknown
./testdisk.img2 39296 117503 78208 38.2M unknown
./testdisk.img3 117504 204671 87168 42.6M unknown


After my diff and the same process as above,
after deleting and creating testdisk.img again:

Disk ./testdisk.img: 100 MiB, 104857600 bytes, 204800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: EEEFD1FE-2CF9-8144-B431-C4A5549419B1

Device Start End Sectors Size Type
./testdisk.img1 128 39295 39168 19.1M Microsoft basic data
./testdisk.img2 39296 117503 78208 38.2M Linux filesystem
./testdisk.img3 117504 204671 87168 42.6M Microsoft basic data


I also attached some links and more information in the PR.
PR: https://github.com/HelenOS/helenos/pull/231


--
mc


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] HelenOS Camp 2024

2024-06-10 Thread Jiri Svoboda

Hi Jakub,




here's my availability:




Week 1 (29.6.- 5.7.) XXX
Week 2 ( 6.7.-12.7.) XXX
Week 3 (13.7.-19.7.) AAA
Week 4 (20.7.-26.7.) AAA
Week 5 (27.7.- 2.8.) XAA
Week 6 ( 3.8.- 9.8.) AAA
Week 7 (10.8.-16.8.) XXX
Week 8 (17.8.-23.8.) AAA
Week 9 (24.8.-30.8.) XXX





It would be great if we can finalize the schedule, say, within a week, so 
that I can make other summer vacation plans.




Thanks

Jiri




-- Původní e-mail --
Od: Jiří Zárevúcky 
Komu: HelenOS development mailing list 
Datum: 9. 6. 2024 12:42:53
Předmět: Re: [HelenOS-devel] HelenOS Camp 2024
"
I have no concrete constraints, you can consider me free all summer.



On Sun, Jun 9, 2024, 12:00 PM Jakub Jermář mailto:ja...@jermar.eu)> wrote:

"Hi,

I was reminded of this so let's see what the time possibilities are.
Please indicate your availability during the summer ('X' for not
available, 'A' for available, '?' undecided). For me it looks like this:

Week 1 (29.6.- 5.7.) AA?
Week 2 ( 6.7.-12.7.) ??A
Week 3 (13.7.-19.7.) AAA
Week 4 (20.7.-26.7.) ?XX
Week 5 (27.7.- 2.8.) XXX
Week 6 ( 3.8.- 9.8.) ?AA
Week 7 (10.8.-16.8.) AAA
Week 8 (17.8.-23.8.) AA?
Week 9 (24.8.-30.8.) ???

Cheers,
Jakub

On 7/26/23 11:09 AM, Jakub Jermář wrote:
> Hi,
>
> the last HelenOS Camp took place in 2019. If there is enough interest,
> I'd like to organize another one in the summer season of 2024 somewhere
> in the Czech mountainous countryside (i.e. the good old HelenOS Camp).
>
> Let me know if you'd like to attend and whether we should start
> organizing this.
>
> Jakub
>
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz(mailto:HelenOS-devel@lists.modry.cz)
> http://lists.modry.cz/listinfo/helenos-devel
(http://lists.modry.cz/listinfo/helenos-devel)


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz(mailto:HelenOS-devel@lists.modry.cz)
http://lists.modry.cz/listinfo/helenos-devel
(http://lists.modry.cz/listinfo/helenos-devel)
"
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] HelenOS 0.14.1 (Aladar) released

2024-05-19 Thread Jiri Svoboda

Silly me, I forgot to mention the What's new video. This time I really took
my time making it, so I hope you will really enjoy it!




See it here:


https://www.youtube.com/watch?v=eLPpnfpLMys





Cheers,

Jiri

-- Původní e-mail --
Od: Jiri Svoboda 
Komu: helenos-devel@lists.modry.cz
Datum: 19. 5. 2024 23:54:35
Předmět: [HelenOS-devel] HelenOS 0.14.1 (Aladar) released
"Hello everyone!

HelenOS 0.14.1 (Aladar) has been released!

This release introduces the start menu, window minimization, system menus,
multi-seat support and more.

More information can be found in the release notes:

http://www.helenos.org/wiki/ReleaseNotes/0.14.1

You can download HelenOS 0.14.1 from our download page:

http://www.helenos.org/wiki/Download

Enjoy,
Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS 0.14.1 (Aladar) released

2024-05-19 Thread Jiri Svoboda
Hello everyone!

HelenOS 0.14.1 (Aladar) has been released!

This release introduces the start menu, window minimization, system menus,
multi-seat support and more.

More information can be found in the release notes:

http://www.helenos.org/wiki/ReleaseNotes/0.14.1

You can download HelenOS 0.14.1 from our download page:

http://www.helenos.org/wiki/Download

Enjoy,
Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of HelenOS online meeting 2024-05-09

2024-05-10 Thread Jiri Svoboda
Minutes of HelenOS online meeting 2024-05-09


Attendees:
  JJ - Jakub Jermář
  JSv - Jiří Svoboda
  NK - Nataliia Korop

Slip configuration discussion
  - http://www.helenos.org/wiki/UsersGuide/Networking#SLIPconfiguration

Round table
---
NK: Packet capture update/questions
  - currently we can select any NIC and capture Ethernet frames
  - the driver writes directly into a file - implemented in libnic
  - thinking about allowing capturing frames from multiple NICs at the same
time
 - JS: Is this even supported in any other OS/tool? (Linux, Wireshark,
snoop, etc.)
  - question: what are the net/ethN services?
 - JS: each net/ethN is an 'IP datalink' - it transports IP datagrams
 - JS: there is one net/ethN instance for each NIC. Although all are
handled by the
   same task
  - question: Is there a place where we could capture frames from all NICs,
where they are already multiplexed?
 - JS: Not really. You don't want to capture in the IP stack (ethip,
inetsrv), because you would loose frames from NICs that are not running IP.
in inetsrv you would also loose the ethernet headers. The correct solution
would be to capture in each of the NICs and then combine the streams. E.g.
have a capture tool that would connect to each NIC and pull data from them.
Still is this even required?
   - question: I've found out that sometimes the name of the capture file
contains garbage characters at the end. Is this a known bug?
 - JS/JS: Not as far as we know.
 - JS: Check your code if it correctly null-terminates the file name
string
 - JJ: Try printing the name of the file being created, either as text
or numeric character codes

JJ:
  - No updates

JSv:
  - release update
    - everything is ready for the release, just waiting for Martin to
provide me with access to upload the files
  - disk benchmarks
    - random read and sequential read, added to hbench
    - 530 ops/s (~250 kB/s) on both with Qemu-kvm (slow!) likely because PIO
is slow in KVM
  - ATA driver
    - the driver can now handle >512 B in a single I/O operation (multiple
DRQ cycles)
    - implemented support for IRQs - frees up CPU to do other things while
waiting for block to be read or written (small ~8% performance improvement
in Qemu-kvm)
    - want DMA to make it faster
    - ISA IDE only supports PIO (ISA DMA is only used with floppy and PC-XT
HDD controllers)
    - JJ: What in HelenOS uses ISA DMA?
   - JS: SoundBlaster driver
    - for DMA, need to add PCI IDE driver
  - the plan is to split generic ATA code to libata, then have two
separate drivers, one for ISA and one for PCI
  - looked at SATA driver
    - doesn't look too bad, but seems there are some bugs to fix
    - need to remove proxy server (not needed anymore)
    - currently requires disk to support NCQ (could be a problem outside
Qemu)

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS online meeting 2024-04-11

2024-04-11 Thread Jiri Svoboda
Minutes of the HelenOS online meeting 2024-04-11


Attendees:
  - JS Jiří Svoboda
  - JJ
  - JZr
     

Scribe: JS

Round table
===

JZr
===
  - no update
  - JS: kindly asks JZr to work on tickets #867, #859

JJ
==
  - nothing to report

JS
===
  - ATA driver work
    - prepared protocol functions to support I/Os larger than 512 B
    - changed withheld until after release and when disk benchmark is
available
  - Fixing GZX for HelenOS
    - ui_wdecor_rect_from_app() prototype changed
    - libinput now required
    - update README.md building for HelenOS instructions
    - fix default export dir in helenos-pkg-config
    - add libconsole, libinut, liboutput to list of exported libaries in
tools/export.sh
    - add libconsole/input/output to list of libraries installed when CONFIG
_DEVEL_FILES is enabled
  (this list is also used to know which headers need to be exported to
XCW/coastline
  - Harbours
    - Bumped GZX in Harbours to get fixed
    - Bumped zlib 1.3->1.3.1 (sources for old version are no longer
available)

  - Preparing for release
    - applied workaround for ia64
    - built and tested release files
    - updated screenshots and release notes
    - pending: finish what's new video

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS online meeting TODAY Thursday 2024-04-11 @ 21:30 GMT+0200

2024-04-11 Thread Jiri Svoboda

Hi all,




our regular online meeting is happening today at 21:30 CEST. I already sent
an invitation/reminder to those on the participants list. If you didn't 
receive an invitation, but would still like to join us, please let me know.




Thanks,

Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Fwd: Re: [HelenOS-tickets] [HelenOS] #866: console input freezes on ia64/ski after GCC upgrade

2024-03-21 Thread Jiri Svoboda

Hi Jakub,




unfortunately whenever I try to instrument the code, it then fails in a 
different place/different way.





The problem goes away with -O1 or -O2. If I compile with -O2, but use -fno-
xxx to manually disabled all the extra optimizations that are enabled with -
O3 per gcc man page, I still get the problem. So unfortunately I don't know
which exact optimization is causing this.




Nevertheless we could build Itanium with -O2 as a workaround for the time 
being. We also need to find some better way of debugging this.




Thanks,

Jiri

-- Původní e-mail --
Od: Jakub Jermář 
Komu: helenos-devel@lists.modry.cz
Datum: 19. 3. 2024 21:30:20
Předmět: Re: [HelenOS-devel] Fwd: Re: [HelenOS-tickets] [HelenOS] #866:
console input freezes on ia64/ski after GCC upgrade
"Hi Jiri,

On 3/19/24 16:48, Jiri Svoboda wrote:
> Hi,
>
> I am working on http://www.helenos.org/ticket/866
>
> Looks too me like VFS crashed because of null pointer dereference on the
> first line of fibril_mutex_unlock(), which is an assert.

This sounds suspiciously like some left-over after #864 - the same area
of code.

> Could an Itanium expert help me, please?
>
> The instruction seems to be:
>
> 4001d240:   11 08 01 40 18 10   [MIB]   ld8 r33=[r32]
>
> looks like we are reading r32. Is that the first argument to the
procedure?

Yes, this will be in0 after the alloc instruction.

> To continue I would like to know the address of the calling function.
> Stack tracing is not implemented on ia64. I looked into the Itanium
> Software convetions and I am confused.. it kind of says it's up to the
> OS? And nothing in the ABI processor supplement. Any suggestions on how
> to actually do it?

So I don't remember how I actually figured out the caller for #864,
probably I added some printfs or detected the condition using an if and
then printed the caller using __builtin_return_address?

Cheers,
Jakub

>
> Or other suggestions?
>
> Thanks,
> Jiri
>
> -- Původní e-mail --
> Od: HelenOS 
>
> Kopie: helenos-tick...@lists.modry.cz
> Datum: 19. 3. 2024 15:36:09
> Předmět: Re: [HelenOS-tickets] [HelenOS] #866: console input freezes on
> ia64/ski after GCC upgrade
>
>
> #866: console input freezes on ia64/ski after GCC upgrade
> ---+---
> Reporter: Jiří Zárevúcky | Owner: (none)
> Type: defect | Status: new
> Priority: major | Milestone: 0.14.1
> Component: helenos/kernel/ia64 | Version: mainline
> Resolution: | Keywords:
> Blocker for: | Depends on:
> See also: |
> ---+---
> Comment (by Jiri Svoboda):
>
> I think it's crashing here:
>
> {{{
> static void _fibril_mutex_unlock_unsafe(fibril_mutex_t *fm)
> {
> assert(fm->oi.owned_by == (fibril_t *) fibril_get_id()); <---
> NULL pointer dereference??
>
> if (fm->counter++ < 0) {
> awaiter_t *wdp = list_pop(&fm->waiters, awaiter_t, link);
> assert(wdp);
>
> fibril_t *f = (fibril_t *) wdp->fid;
> fm->oi.owned_by = f;
> f->waits_for = NULL;
>
> fibril_notify(&wdp->event);
> } else {
> fm->oi.owned_by = NULL;
> }
> }
> }}}
> --
> Ticket URL: <http://www.helenos.org/ticket/866#comment:6>
> HelenOS <http://www.helenos.org/>
> HelenOS Operating System
> ___
> HelenOS-tickets mailing list
> helenos-tick...@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-tickets
>
>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Fwd: Re: [HelenOS-tickets] [HelenOS] #866: console input freezes on ia64/ski after GCC upgrade

2024-03-19 Thread Jiri Svoboda

Hi,




I am working on http://www.helenos.org/ticket/866




Looks too me like VFS crashed because of null pointer dereference on the 
first line of fibril_mutex_unlock(), which is an assert.



Could an Itanium expert help me, please?



The instruction seems to be:




4001d240:   11 08 01 40 18 10   [MIB]   ld8 r33=[r32]




looks like we are reading r32. Is that the first argument to the procedure?




To continue I would like to know the address of the calling function. Stack
tracing is not implemented on ia64. I looked into the Itanium Software
convetions and I am confused.. it kind of says it's up to the OS? And
nothing in the ABI processor supplement. Any suggestions on how to actually
do it?




Or other suggestions?


Thanks,

Jiri



-- Původní e-mail --
Od: HelenOS 

Kopie: helenos-tick...@lists.modry.cz
Datum: 19. 3. 2024 15:36:09
Předmět: Re: [HelenOS-tickets] [HelenOS] #866: console input freezes on ia
64/ski after GCC upgrade
"#866: console input freezes on ia64/ski after GCC upgrade
---+---
Reporter: Jiří Zárevúcky | Owner: (none)
Type: defect | Status: new
Priority: major | Milestone: 0.14.1
Component: helenos/kernel/ia64 | Version: mainline
Resolution: | Keywords:
Blocker for: | Depends on:
See also: |
---+---
Comment (by Jiri Svoboda):

I think it's crashing here:

{{{
static void _fibril_mutex_unlock_unsafe(fibril_mutex_t *fm)
{
assert(fm->oi.owned_by == (fibril_t *) fibril_get_id()); <---
NULL pointer dereference??

if (fm->counter++ < 0) {
awaiter_t *wdp = list_pop(&fm->waiters, awaiter_t, link);
assert(wdp);

fibril_t *f = (fibril_t *) wdp->fid;
fm->oi.owned_by = f;
f->waits_for = NULL;

fibril_notify(&wdp->event);
} else {
fm->oi.owned_by = NULL;
}
}
}}}
--
Ticket URL: <http://www.helenos.org/ticket/866#comment:6>
HelenOS <http://www.helenos.org/>
HelenOS Operating System
___
HelenOS-tickets mailing list
helenos-tick...@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-tickets
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of HelenOS online meeting 2024-03-14

2024-03-15 Thread Jiri Svoboda

Hi all,




thanks to everybody who attended the meeting yesterday! Please find the 
minutes from the meeting below.




Cheers,

Jiri




Minutes of HelenOS online meeting 2024-03-14


Attendees:
  MC - Miroslav Cimerman
  VH - Vojtěch Horký
  JJ - Jakub Jermář
  NK - Nataliia Korop
  JS - Jiří Svoboda
  VS - Vít Skalický
  MV - Matěj Volf

Scribe:
  JS

Round table
===

MV:
  - will be working working on porting Rust to HelenOS as a school 
assignment (ročníkový projekt)
  - so far managed to compile HelenOS
  - still waiting for Trac access
VS:
  - will be working on read-only Btrfs driver as a school assignment 
(ročníkový projekt)
  - JS: For reference, GRUB has a read-only Btrfs driver, from there you can
judge e.g. amount of work
  - VH: We might strip it down even more, omitting support for mirror/
stripe/etc.
MC:
  - will be working on software raid as a school assignment (ročníkový
projekt)
  - JS: Something like Solaris LVM? (mirror, stripe for block devices) VH:
Yes

JJ:
  - no progress update

NK:
  - discussion of NIC selection for packet capture tool
  - would really like to use short names. Can't we use net/ethN?
  - JS: I really don't think this is the right think to do. I don't think
you need to solve this as part of your assignment. It's a project on its 
own. I suggest 1) if there is just one NIC, just use that 2) if there are 
more and user didn't specify one, prompt interactively or, alternatively, 
allow user to specify NIC index like with NIC tool
  - JJ: What about capturing datagrams from SLIP? JS: You could add capture
to SLIP as well. But then, you can have other capture sources than NICs. So
you would have to have a subcommand to list capture sources (with indices)
and then you could specify capture source with index (or select
interactively).
  - discussion which NIC drivers are supported

VH:
 - fixing bugs in automatic test script
 - still cannot root cause erratic loss simulated key presses in Qemu
 - question: Is there any NIC you can currently buy that we support?
   JS: Don't know. Do you actually have a PC where you can plug it in where
we can boot and support interrupts?

JS:
  - How about releasing 0.14.1? Looks like a good time to do so. JJ, VH:
Shrugs of consent
 VH: Look at ci.helenos.org, looks like builds have been failing lately.
Needs fixing prior release
  - Any volunteer to be the release manager? .. no volunteers -> JS will be
RM for 0.14.1
  - Is persistent device identification/naming a good student assignment?
VH: We would need to narrow it down make sure it's not too large.
  - JS: I would like to implement staged bood. Requires global chroot or
pivot mount. Would JJ like to work on it? JJ: not really
  - Very happy about all the student interest!

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Reminder: Online meeting Thursday 2024-03-14 at 21:30 GMT+0100

2024-03-13 Thread Jiri Svoboda
Hi all,




I would like to remind you that our regular HelenOS online meeting is taking
place tomorrow, 2024-03-14 at 21:30 CET. I have already sent an invitation
to all in the participants list. If you didn't receive it, but would still
like to join us, please let me know.


Agenda:
  - fixing regressions #859, #867 (JZr)
  - release planning (0.14.1)
  - packet capture NIC selection (NK)
  - persistent device identification
  - staged boot + chroot/pivot mount (JJ)
  - round table

Looking forward to seeing you there!

Cheers,
Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Mapping between net/eth1 and devices\/\\hw\\sys\\00:03.0\\port0

2024-03-12 Thread Jiri Svoboda

Hi Nataliia,





> I wonder if there is any mapping between net/eth1 and devices\/\\hw\\sys\\
00:03.0\\port0? Or any other mapping with shorter > names?

There isn't. HelenOS doesn't have any 'short names' for devices (at least 
not yet).

net/eth1 is not a short name for devices\/\\hw\\sys\\00:03.0\\port0 they are
two different things.




devices\/\\hw\\sys\\00:03.0\\port0 is a NIC (thing that transports Ethernet
frames), service provided by the NIC driver


net/eth1 is an "IP link" (thing that transports IP datagrams), service
provided by ethip (IP over Ethernet transport service)






> I can get "devices\/\\hw\\sys\\00:03.0\\port0" from category "pcap" with
help of locsrv. And now "pcapctl list" returns

> these long names. But it would be easier for user to write "pcapctl start
net/eth1 d.pcap" than

> "pcapctl start devices\/\\hw\\sys\\00:03.0\\port0 d.pcap".


net/eth1 is not another name for the NIC so that does not really make sense.
net/eth1 is on a different layer.




The problem of "short names" hasn't been fully addressed yet. In most cases
"full device names" like devices\/\\hw\\sys\\00:03.0\\port0 are used to 
refer to devices (e.g. in 'mount' command).


Here are some approaches that have been taken to make this a little less 
painful:




1. We make use of locfs mounted in /loc which mirrors the device tree. If 
you "cd /loc", then you can use tab to auto-complete device names




2. The autors of "nic" utility chose to specify NICs using their index in 
the NIC listing. If you run "nic" it prints an index (0, 1, ..) for each 
NIC, then you use "nic  " to manipulate them. It's not 
ideal (e.g. if the list changes), but it's sort of similar to a situation 
where you would have an UI and select the NIC from a list.






Perhaps you could also allow skipping the NIC specification if there is just
one (I think that's what iwconfig in Linux does).

You could also, if the NIC is not specified and there are more than one, 
prompt the user to select from a list (using nchoice from libclui) (no, 
really!)




Hope this helps a bit.




Cheers,

Jiri






PS. Sorry, the spam filter put this in my Spam folder, so I didn't notice it
earlier.




-- Původní e-mail --
Od: Nataliia Korop 
Komu: helenos-devel@lists.modry.cz
Datum: 10. 3. 2024 16:58:08
Předmět: [HelenOS-devel] Mapping between net/eth1 and devices\/\\hw\\sys\\
00:03.0\\port0
"

Hello,


still doing thesis on ticket 629. I am currently working on option "pcapctl
list" for listing possible devices, packets from which can be dumped.





I wonder if there is any mapping between net/eth1 and devices\/\\hw\\sys\\
00:03.0\\port0? Or any other mapping with shorter names?





I can get "devices\/\\hw\\sys\\00:03.0\\port0" from category "pcap" with 
help of locsrv. And now "pcapctl list" returns these long names. But it 
would be easier for user to write "pcapctl start net/eth1 d.pcap" than
"pcapctl start devices\/\\hw\\sys\\00:03.0\\port0 d.pcap".





The only thing I found is that the name "net/eth1" is related to nic
structure and for option "inet list-addr" link names are saved in advance 
during some initialization and that list is stored and returned when needed,
so I am a bit stuck.





Any advice would be appreciated,

Nataliia Korop


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] USB Tablet HID report descriptors

2024-03-09 Thread Jiri Svoboda
Hi,


for a long time I had the idea that USB digitizer tablets can report In 
range / Out of range events when the pen gets close enough / away from the
tablet's surface. I thought that Qemu / VirtualBox would generate those 
events when the mouse pointer enters/leaves the VM window. So I thought we
could hide the cursor upon reception of Out of Range and show it upon
reception of In range.




I thought I filed an ER for this, but I can't find it so perhaps I didn't.


So I went and enhanced HelenOS USB HID driver to report Digitizer / In Range
and Digitizer / Out of Range events. And... nothing.

So I dumped the HID report descriptors for Qemu -device usb-tablet and
VirtualBox with USB Tablet input device.

For the full listing, see below.

Summary:

Qemu (48 bits total)

3x 1 bit (3 buttons)
5 bits of padding
16 bits X
16 bits Y
8 bits wheel

VirtualBox (48 bits total)

5x 1 bit (5 buttons)
3 bits of padding
8 bits wheel
8 bits Page 0xC / Usage 0xEE (Consumer / Reserved) ???
8 bits padding
16 bits X
16 bits Y

I'm not sure what is the 0xC/0xEE, but I verified it is zero regardless of
whether the pointer is inside/ouside of the window.

So it looks like I was wrong the whole time and emulators do not send In 
Range / Out of Range events. I though this would be logical, but perhaps I
was wrong. Also I am not sure if window systems would actually hide the 
pointer if you get out of range. Now that I think about it I think they don'
t. Afterall, you can still control the pointer e.g. with your mouse.

Then again in a situation where you have a mouse/touchpad AND a tablet, I 
would prefer to have TWO POINTERS and hide the tablet's pointer when the 
stylus is not in range. (But I'd still like to have them share the same 
keyboard focus ... that's actually not something you can currently do with
HelenOS.. as each seat can only have one pointer. Two pointers == two 
keyboard foci... An actually interesting use case that I havent't thoughr of
before. Maybe we could allow multiple pointers within a seat. Would be
rather easy to do (except we'd really need a tree view for the
configuration).




[I mostly just wanted to record this information for future reference.]




Cheers,
Jiri


Qemu -device usb-tablet
===
[usbhid] note: Report ID: 0
[usbhid] note:     Type: 1
[usbhid] note:     Length: 48
[usbhid] note:     B Size: 6
[usbhid] note:     Items: 7
[usbhid] note:         OFFSET: 0
[usbhid] note:         SIZE: 1
[usbhid] note:         LOGMIN: 0
[usbhid] note:         LOGMAX: 1
[usbhid] note:         PHYMIN: 0
[usbhid] note:         PHYMAX: 0
[usbhid] note:         tUSAGEMIN: 0
[usbhid] note:         USAGEMAX: 0
[usbhid] note:         USAGES COUNT: 0
[usbhid] note:         VALUE: 0
[usbhid] note:         tUSAGE: 1
[usbhid] note:         USAGE PAGE: 9
[usbhid] note: USAGE_PATH FOR RId(0):
[usbhid] note:     LENGTH: 3
[usbhid] note:     USAGE_PAGE: 1
[usbhid] note:     USAGE: 2
[usbhid] note:     FLAGS: 0
[usbhid] note:     USAGE_PAGE: 1
[usbhid] note:     USAGE: 1
[usbhid] note:     FLAGS: 0
[usbhid] note:     USAGE_PAGE: 9
[usbhid] note:     USAGE: 1
[usbhid] note:     FLAGS: 0
[usbhid] note:         OFFSET: 1
[usbhid] note:         SIZE: 1
[usbhid] note:         LOGMIN: 0
[usbhid] note:         LOGMAX: 1
[usbhid] note:         PHYMIN: 0
[usbhid] note:         PHYMAX: 0
[usbhid] note:         tUSAGEMIN: 0
[usbhid] note:         USAGEMAX: 0
[usbhid] note:         USAGES COUNT: 0
[usbhid] note:         VALUE: 0
[usbhid] note:         tUSAGE: 2
[usbhid] note:         USAGE PAGE: 9
[usbhid] note: USAGE_PATH FOR RId(0):
[usbhid] note:     LENGTH: 3
[usbhid] note:     USAGE_PAGE: 1
[usbhid] note:     USAGE: 2
[usbhid] note:     FLAGS: 0
[usbhid] note:     USAGE_PAGE: 1
[usbhid] note:     USAGE: 1
[usbhid] note:     FLAGS: 0
[usbhid] note:     USAGE_PAGE: 9
[usbhid] note:     USAGE: 2
[usbhid] note:     FLAGS: 0
[usbhid] note:         OFFSET: 2
[usbhid] note:         SIZE: 1
[usbhid] note:         LOGMIN: 0
[usbhid] note:         LOGMAX: 1
[usbhid] note:         PHYMIN: 0
[usbhid] note:         PHYMAX: 0
[usbhid] note:         tUSAGEMIN: 0
[usbhid] note:         USAGEMAX: 0
[usbhid] note:         USAGES COUNT: 0
[usbhid] note:         VALUE: 0
[usbhid] note:         tUSAGE: 3
[usbhid] note:         USAGE PAGE: 9
[usbhid] note: USAGE_PATH FOR RId(0):
[usbhid] note:     LENGTH: 3
[usbhid] note:     USAGE_PAGE: 1
[usbhid] note:     USAGE: 2
[usbhid] note:     FLAGS: 0
[usbhid] note:     USAGE_PAGE: 1
[usbhid] note:     USAGE: 1
[usbhid] note:     FLAGS: 0
[usbhid] note:     USAGE_PAGE: 9
[usbhid] note:     USAGE: 3
[usbhid] note:     FLAGS: 0
[usbhid] note:         OFFSET: 3
[usbhid] note:         SIZE: 5
[usbhid] note:         LOGMIN: 0
[usbhid] note:         LOGMAX: 1
[usbhid] note:         PHYMIN: 0
[usbhid] note:         PHYMAX: 0
[usbhid] note:         tUSAGEMIN: 0
[usbhid] note:         USAGEMAX: 0
[usbhid] note:         USAGES COUNT: 0
[usbhid] note:      

Re: [HelenOS-devel] #358 IRQ code compiler as student project

2024-03-04 Thread Jiri Svoboda

Hi Matěj,




thanks for your interest! I think the ticked should be still up to date. I
don't think there have been any changes in this area. I think this still 
makes sense and it is an interesting project.




It makes sense to try and keep the compiler simple not to kill an ant with a
nuclear bomb, given that the total amount of IRQ pseudocode in HelenOS is 
rather small and the problems solved are often simple.


The primary goal is to make it easier and more obious than currently, where
the code is written as an array, where we often either put numbers that 
denote arguments (not very obvious) and fill in some values at run time 
(even less obvious). Even if it would be just an "assembler' that translates
the IRQ pseudocode instructions from some nice text representation, it would
be an advantage. I am OK with a more high-level language as long as it does
not complicate the compiler too much. (Should be OK if the language is
simple).




I don't have management access to Trac, but I am sure Martin or Jakub can 
take care of that.





Cheers,

Jiri




-- Původní e-mail --
Od: Matěj Volf 
Komu: helenos-devel@lists.modry.cz
Datum: 2. 3. 2024 17:23:19
Předmět: [HelenOS-devel] #358 IRQ code compiler as student project
"Hi all,

I am in my second year of Computer Science at MFF, so I'm currently
choosing a topic for my student project. From the archived GSoC idea
lists I found http://www.helenos.org/ticket/358 , which looks very
interesting to me. Is the information there still valid? Was there any
relevant progress in interrupt handling since this was written? I
briefly checked the code and the irq_cmd_t structures are still present 
in many places in the code, so I suppose a better solution wasn't found 
yet, but I'm still asking since it's quite an old ticket.

Of course, before starting some implementation, I'd draft the pseudocode 
spec to make sure it suits all needs. But I want to avoid diving into
understanding the interrupt handling before knowing at least that there 
is still some interest in this.

Also I would like to ask to register a Trac user account to continue the 
discussion in the ticket thread - the registration page pointed me to
ask in this list.

Thanks

Matěj Volf


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] How to display/interpret benchmark results?

2024-01-23 Thread Jiri Svoboda

Hi,




Currently hbench selects the number of cycles, takes 10 time measurements.
It then computes the average and standard deviation of the time taken. It 
then computes and displays the rate from the average time and cycle count.




I am really interested in the rate, not the time. What I am missing is a 
number on the spread of the rate.

What is the correct way of doing this?

Is it correct to compute the rate from the average time? Or should we
average the rates and get SD from there?




Any comments, suggestions? Any statistics experts out there?




Thanks,

Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Benchmarks for scheduler refactor changes

2024-01-23 Thread Jiri Svoboda

Hi,




while I didn't have the time yet to go through the scheduler changes in 
detail to try and understand them, I was wondering what (if any) effect they
have on performance. I ran a couple of benchmarks. Here's the results:





Qemu + KVM amd64

top busy 6.5-7.4% both
ping_pong old: 70167 ops/s new: 77737 ops/s
taskgetid: old 3637731 ops/s new 5833524 ops/s ()
read1k: old 13826 ops/s new 15073 ops/s
fibril_mutex: old 13432519 ops/s new 13497358 ops/s
malloc1: old 5878492 ops/s new 5870265 ops/s

Qemu without KVM amd64
==
top busy: old 50% new: 50%c
ping_pong: old 2519 ops/s new 2697 ops/s
taskgetid: old 625269 ops/s new 1389736 ops/s ()
read1k: old 634 ops/s 656 ops/s
fibril_mutex: old 572367 ops/s 585143 ops/s
malloc1: old 355691 ops/s 345153 ops/s


The most obvious is that taskgetid performance increased about 2x ()

We can also see a more moderate (10%) increase in ping_pong and still more
moderate in read1k. fibril_mutex and malloc1 are the same within the error
margin.




Regards,

Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS online meeting 2023-12-14 @ 21:30 CET/GMT+0100

2023-12-13 Thread Jiri Svoboda

Hi folks,




our regular online meeting will take place tomorrow, Thursday 2023-12-14 at
21:30 CET/GMT+0100 via Google Meet. I have sent a reminder to those listed
as attendees. If you did not receive it, but would still like to join,
please let me know.




Thanks,
Jiri___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS online meeting 2023-11-09

2023-11-10 Thread Jiri Svoboda

Hi,




we've had a great meeting with a record-breaking attendance (well, at least
attendance not seen for a long long time ^_^). Thanks to everybody who
joined. Please find the minutes of the meeting attached. Let's hope this 
will be the rule rather than the exception ^_^.




Cheers,

Jiri

Minutes of the HelenOS online meeting 2023-11-09


Attendees:
  JJ - Jakub Jermář
  JS - Jiří Svoboda
  JZr - Jiří Zárevúcky
  MD - Martin Děcký
  VH - Vojta Horký

Scribe:
  JS

Round table
---
 JJ - Nothing

VH
==
 - in process of migrating ci.helenos.org backend to new machine
 - will be looking into issues
   - arm64 not building
   - coastline not building
   - some might be actual bugs in the source code
 - MSIM news
   - now suppors RISC-V RV32IMA CPU (potential for new port)
   - work is in progress to support graphical output

MD
==
 - Coded nothing in the last year
 - FOSDEM microkernel devroom approved
   - Suggests somebody should attend and deliver a HelenOS talk
 - July helenos.org moved to new machine
   - new Trac version caused change of appearance, needs to be re-styled

 - Suggests HelenOS meeting in person in a pub
   - in January?

JZr
===
 - helped merge toolchain update
 - fixed linker scrips for kernel/boot  so that gc-sections work
 - some code was duplicated between kernel and uspace
str, printf_core
   - moved to new directory common
 JS: adt/prodcos in common is strange
- JZr: will move to libc
 - reading debug info : file name / line number in kernel and for init task 
faults
 - works on all platforms

  JJ: You updated GCC to 13.2, not just 13.1
   JZr: yes, also updated to latest version of binutils
  
  Working on: lazier framebuffer
   - this spawned a discussion that this should not be necessary, also 
continued in e-mail

JS
==
 - Worked on start menu editor
   - Can change entry name and caption
   - but need to restart editor to update listing
   - need to restart task bar to see updated start menu
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Kernel framebuffer bottlenecks

2023-11-10 Thread Jiri Svoboda

"
No. It will update the screen for every character/newline printed. But
stdout in C is line-buffered by default, so only full lines get sent to the
console (if we are talking about userspace).
"
Correction: it updates the screen for every write(2) operation.





-Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Kernel framebuffer bottlenecks

2023-11-10 Thread Jiri Svoboda

No. It will update the screen for every character/newline printed. But
stdout in C is line-buffered by default, so only full lines get sent to the
console (if we are talking about userspace).




If there is an inherent problem in updating a graphical console in Qemu, it
should affect Linux graphical console too. Maybe you should try running a 
linux with graphical console in your Qemu and try to compare the results. If
the problem does not occur with Linux, might be good idea to investigate 
exactly what the difference is.





Cheers,

Jiri

-- Původní e-mail --
Od: Martin Decky 
Komu: helenos-devel@lists.modry.cz
Datum: 10. 11. 2023 10:20:59
Předmět: Re: [HelenOS-devel] Kernel framebuffer bottlenecks
"BTW: One optimization that the Linux kernel console is probably doing is 
not necessarily drawing and scrolling on every new line of output, but
only on an explicit flush.

It is common that most run-time environments flush on a newline (when
writing to stdout), but not necessarily on every newline, but maybe only 
on the last newline of the given print statement.

Maybe this is a way to do some cheap and conservative optimizations for 
our kernel console as well, at the expense of some output buffering on
the "stdout" side in the kernel. Of course, critical kernel messages
need to be printed in the "stderr" style with implicit flushes after
every character like now.

I'm not sure how much would this actually help and whether it is worth
the complications.


M.D.

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS online meeting 2023-11-09 @ 21:30 CET/GMT+0100

2023-11-08 Thread Jiri Svoboda

Hi folks,




our regular online meeting will take place tomorrow, Thursday 2023-11-09 at
21:30 CET/GMT+0100 via Google Meet. I have sent a reminder to those listed
as attendees. If you did not receive it, but would still like to join,
please let me know.




Thanks,

Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Coastline builds failing on ci.helenos.org

2023-10-22 Thread Jiri Svoboda


Hi,




I fixed export.sh to deal with thin archives and fixed conflict in GZX that
was causing its coastline build to fail. I went to check on ci.helenos.org
if it worked and now I see *all* coastline builds of all packages on ci.
helenos.org failing in a strange way.

It fails while trying to build binutils. Any idea what's going on?




Thanks,

Jiri





Build log example:



>>> Fetching sources...
filename:'binutils-2.21.1.tar.bz2' 
url:'http://ftpmirror.gnu.org/binutils//binutils-2.21.1.tar.bz2'
filename:'pex-helenos.c' url:'pex-helenos.c'
>>> Building...
[hsct]: "tar" "xjf" "binutils-2.21.1.tar.bz2"
>>> Weakening some symbols...
[hsct]: "sed" "1i#pragma weak optind" "1i#pragma weak optarg" "1i#pragma weak 
opterr" "1i#pragma weak optopt" "1i#pragma weak getopt" "-i" 
"binutils-2.21.1/libiberty/getopt.c"
[hsct]: "sed" "1i#pragma weak getopt_long" "-i" 
"binutils-2.21.1/libiberty/getopt1.c"
[hsct]: "sed" "1i#pragma weak strncmp" "-i" 
"binutils-2.21.1/libiberty/strncmp.c"
[hsct]: "sed" "1i#pragma weak fnmatch" "-i" 
"binutils-2.21.1/libiberty/fnmatch.c"
>>> Providing our pex implementation...
[hsct]: "cp" "pex-helenos.c" "binutils-2.21.1/libiberty/"
[hsct]: "sed" "s/@pexecute@/pex-helenos/" "s/pex-msdos/pex-helenos/g" "-i" 
"binutils-2.21.1/libiberty/Makefile.in"
[hsct]: "cd" "binutils-2.21.1"
[hsct]: "cp" "/var/helenos/nightly/tmp-ci/repo/coastline/config.sub" "." 
[hsct]: "./configure" "--build=x86_64-pc-linux-gnu" "--host=arm-helenos" 
"CC=arm-helenos-cc" "CXX=arm-helenos-cxx" "AR=arm-helenos-ar" 
"AS=arm-helenos-as" "CPP=arm-helenos-cpp" "NM=arm-helenos-nm" 
"OBJDUMP=arm-helenos-objdump" "OBJCOPY=arm-helenos-objcopy" 
"STRIP=arm-helenos-strip" "RANLIB=arm-helenos-ranlib" "--target=arm-linux-gnu" 
"--program-prefix=" "--disable-werror" "--disable-nls" "--disable-shared" 
"--enable-static" "--with-zlib=no" "--with-ppl=no" "--with-cloog=no" 
"--with-gmp=no" "--with-mpfr=no" "--with-mpc=no"
checking build system type... x86_64-pc-linux-gnu
checking host system type... arm-unknown-helenos
checking target system type... arm-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... gawk
checking for arm-helenos-gcc... arm-helenos-cc
checking for C compiler default output file name...
configure: error: in 
`/var/helenos/nightly/tmp-ci/build/arm32-integratorcp/coast/build/binutils/binutils-2.21.1':
configure: error: C compiler cannot create executables
See `config.log' for more details.
[hsct]: "make" "all-gas" "all-ld" "-j1" "STATIC_ONLY=y"
make: *** No rule to make target 'all-gas'.  Stop.
[hsct]: Error: Build failed!

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS online meeting 2023-10-12

2023-10-17 Thread Jiri Svoboda
Minutes of the HelenOS online meeting 2023-10-12


Attendees:
    JJ - Jakub Jermář
    JS - Jiří Svoboda

Scribe: JS

Notes
=
 - ci.helenos.org is working now
 - Vojta should merge his toolschain update


Progress updates


JJ:
  - debugging itanium with updated toolchain
  - zero passed to futex_unlock
  - looks like a compiler bug?

JS:
  - ofw tool + library (use for ebus on ultra?)
  - fix accel keys not working when caps lock enabled
  - add restore, minimize, maximize entries to system menu
  - loc_sever_register() can be called more than once
 - can only route correctly if each service exports different interface type
  - do not leak memory when realloc fails
  - system menu handle (actually control box in Windows)
  - handover betweem system menu and menu bar (lot of work)

  - start menu
    - place menu above menubar when needed
    - not obscured by task bar
    - load from SIF repo
    - support for arguments (no spaces) -> start in terminal

  - support Alt key in serial console
    (could also add support for Ctrl-Alt)
  - GFX Demo fixes
    - should not print things when starting
    - quit promptly
    - events in console mode
    - window size with -d cons@ ui ... problem with events
  - Lenovo wireless mouse testing #860 - other mice work fine
  - #854 test-libui failures .. closed since it was fixed sometime in the past

  - cannot build coastline .. 
/usr/local/cross/lib/gcc/amd64-helenos/8.2.0/../../../../amd64-helenos/bin/ld: 
/data/helenos/harbours/build/helenos/lib/libclui.a: error adding symbols: 
malformed archive

Interesting points
==
  - cannot configure seats when DS is not running
  - task bar should not start things in terminal when it's running in console
  - task bar should work without DS - still have start menu and clock
  - color scheme config should work without DS

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS online developer meeting Tursday 2023-10-12

2023-10-11 Thread Jiri Svoboda
Hi everyone,

I would like to invite you to our regular online meeting. It is happening 
tomorrow, Thursday, 2023-10-12 at 21:30 CEST (GMT+0200).

We will discuss current progress, issues and so on.

If you don't know if you are in the participant list, please check your 
Google Calendar. If you'd like to join, but are not listed as participant,
please let me know.

See you there!
Cheers,
Jiri

PS: Last time we ran out of the 1 h limit of Google Meet, but we were able
to quickly switch to palava.tv. It works really well, the only issue is it
does not seem to support screen sharing. Otherwise I'd find it preferable to
Google. Also not sure how it would handle a larger number of participants 
(is that likely to happen? ^_^)
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Test report bbxm / Toolchain update (GCC 13.1.1, binutils 2.40) #226

2023-09-29 Thread Jiri Svoboda

Hi folks,




as requested on the last meeting, I tested HelenOS built with the updated 
toolchain from PR 226 with Jakub's BeagleBoard xM which I have on loan. 
Here's a report:




1. Built HelenOS/bbxm from current master using GCC 8.2.0. The OS image 
booted successfully to the expected state (started console tasks, but then
drop to kconsole as no output device is found). See attached serial console
log.




2. Successfully built arm32 toolchain / gcc 13.1.0 using tools/toolchain.sh
from PR 226. Built HelenOS/bbxm from sources from PR 226 using the
aforementioned toolchain (again, no problems). Booted OS image on bbxm. The
system again booted successfully to the expected state. See attached serial
console log.




Summary: It's working! Nice job.





Cheers,

Jiri


Texas Instruments X-Loader 1.5.0 (Mar 27 2011 - 17:37:56)
Beagle xM
Reading boot sector
Loading u-boot.bin from mmc


U-Boot 2011.03-rc1-0-g9a3cc57-dirty (Apr 01 2011 - 17:41:42)

OMAP36XX/37XX-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND 
I2C:   ready
DRAM:  512 MiB  
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0   
*** Warning - readenv() failed, using default environment   

In:serial   
Out:   serial   
Err:   serial   
Beagle xM Rev C 
No EEPROM on expansion board
Die ID #6de200029ff8016849a902025005
Hit any key to stop autoboot:  0
OMAP3 beagleboard.org # 
OMAP3 beagleboard.org # loady   
## Ready for binary (ymodem) download to 0x8020 at 115200 bps...
CCCTX)/0(CAN) packets, 17 retries   
## Total Size  = 0x003ffd5c = 4193628 Bytes 
OMAP3 beagleboard.org # bootm   
## Booting kernel from Legacy Image at 8020 ... 
   Image Name:   HelenOS-0.12.1 
   Image Type:   ARM NetBSD Kernel Image (uncompressed) 
   Data Size:4193564 Bytes = 4 MiB  
   Load Address: 8000   
   Entry Point:  8000   
   Verifying Checksum ... OK
   Loading Kernel Image ... OK  
OK  
## Transferring control to NetBSD stage-2 loader (at address 8000) ...  
HelenOS bootloader, release 0.12.1 (Cathode), revision 4034954ce
Built on 2023-09-28 23:25:54 for arm32  
Copyright (c) 2001-2022 HelenOS project 
Boot loader: 0x8000 -> 0x8000dd1c   

Memory statistics   
 0x8000d000|0x8000d000: bootstrap stack 
 0x80008000|0x80008000: bootstrap page table
 0x8000d818|0x8000d818: boot info structure 
 0x80a0|0x80a0: kernel entry point  
Boot loader: 0x8000 -> 0x8000dd1c   
Payload: 0x8000dd1c -> 0x803ffd1c   
Kernel load address: 0x80a0 
Kernel start: 0x80a0
RAM end: 0x81a0 (16777216 bytes available)  

Inflating components ...
 0x80a0|0x80a0: kernel.elf.gz image (516376/146525 bytes

[HelenOS-devel] Start Menu Architecture proposal

2023-09-26 Thread Jiri Svoboda
Hi all,

I am almost done with the system menu.. just need to finish some unit tests.
Next step is the Start Menu. Since this is supposed to be editable, persistent,
with potentially mutliple readers (instances of Task Bar) and writers (editors),
some architecture design was in order Maybe I should start some section on 
the
wiki for these.

As always, let me know if you have any questions or suggestions.

Cheers,
Jiri!

Start Menu Architecture
===

+--+ +---+
| Task Bar |  <--| Start Menu Editor |    Package manager? CMDline tool?
+--+ notif   +---+
 ||
+--+
| libstartmenu |
+--+
   | |
   ++  +---+
   | libsif |  | async+loc |
   ++  +---+
   |
 /cfg/startmenu.sif

Start menu contents are stored in SIF DB /cfg/startmenu.sif.
libstartmenu implements reading, writing and editing the DB,
as well as notifying other consumers that the DB has changed
and listening for notifications.

Change notifications are implemented as with proposed color scheme
change notification:

Each client registers a service in a particular Location Service category.
The notifier enumerates the category, contacts each service within
and notifies the respective client.

libstartmenu is used by any client reading or modifying the start menu:
  - Task Bar ( / Start Menu)
  - Start Menu Editor (separate task)
  - potentially package manager in the future
  - potentially command-line tool to edit start menu (is this even useful? not 
planning one at this point)

I was considering sending the individual updates via IPC, in order to update
menus 'live' (i.e. even when they are open), but that's probably unnecessarily
complicated, I don't even think menus can handle updates very well while
they are open. So I will opt for a simple notification that something has
changed, after which the notified client will destroy the entrie menu
and re-create it from the DB.

I was also considering an alternate solution, where the Start Editor
would contain the code for editing and the Task Bar would contain the
code to just read the menu from the DB. There would be just a library
to facilitate the IPC communication. But it would havbe the downside
of duplicating the DB read code, plus it would not facilitate other
possible clients (e.g. command line tool, package manager).

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Design thoughts on color scheme change notification mechanism

2023-09-15 Thread Jiri Svoboda
Hi,

for quite some time I've been toying with the idea of implementing some 
color scheme / color editing support in the UI. However, I've been stuck on
the design of a color scheme change notification mechanism.

I think I've finally broken through so I wanted to share my deliberations
so that I have a record of my thoughs.

It is possible they might also apply to other similar problems and I come
to some interesting conclusions that could benefit other areas as well.

Please let me know if you have any comments/suggestions.

Cheers,
Jiri

Design thoughts on color scheme change notification mechanism
=
When a change is made to the color scheme via a configuration window,
runnning applications need to be notified of this change. What
is the approppriate mechanism for this?

1. Via the display server
=
The display server could have a dedicated notification mechanism just for 
this.
This is not elegant, because the display server does not care about
the libui color scheme. Moreover, if there were, hypothetically speaking,
UI toolkits A and B, each would like to use its own notification.
Therefore each UI toolkit needs a dedicated notification channel.
We need a generic/flexible notification mechanism where we can have
potentially multiple notification channels.

2. A notification/configuration server for libui

Running a dedicated server all the time just in case we need to notify
libui users is silly.

3. A generic notification service
=
So how about creating a special notification server, that allows the
creation of notification channels?
- I feel like we should be already able to do this, without a new type of 
naming service!

4. Using the location service
=
Let's put this on its head. Each libui instance will register a unique
service and register in a category/namespace (let it be N). When the
configuration utility makes changes to the color scheme, it will enumerate
all libUI instances in N, connect to each in turn and notify them. They will
re-read the configuration DB and re-paint.

Alternatively, it could push the configuration directly via IPC, although 
this is not necessarily better (or simpler).


I was very happy to come up with (4). This is an elegant solution and it 
does not require any new services.

It does, however, require the compositionality of the API for providing 
services via loc, which we currently lack.

Loc registration API compositionality
=
We need a component (e.g. libui) to be able to register with loc without 
interfering with another independent component (e.g. main(), DDF)
registering with loc from within the same task.

The problem is with loc_server_register(). Either one needs to be able to 
call
it multiple times (and get a handle, then passed to loc_service_register)
or eschew the loc_server_register() altogether. The server has a NAME
parameter which is displayed alongside the service name in the output of 
'loc' utility.

Display server relativity
=
All the above would work great as long as there is a single display server.
If there are more display servers, we need more configuration DBs and
more notification channels.

If we assume that all display servers are processes running on the same 
host,
one could use a trivial mechanism such as constructing the name of
the configuration DB and of the notification channel using the display
server PID (or other display identifier) and looking them up in the local
name services / file system.

If we want to lift ourselvers above such assumptions, here's an idea how
this could be implemented.

Let's assume that for each display server instance D there is an associated
dedicated service namespace NS(D). The display server has a method by which
a client
can obtain the capability NS(D). For notification a libui-specific
notification channel under this namespace will be used NS(D)/libui-notif.

To access the configuration DB, one would need access to the relevant file.
Registering the host's VFS service under NS(D)/libui-vfs is not adequate.
It would not work for the case of multiple display servers running on the
same host.

Instead, it would be adequate if we could register a capability to a
particular
file into the namespace. This alas cannot be done with the current VFS
implementation.

Conclusion
==
A simple and elegant color scheme change notification mechanism can be
implemented depending on making loc registration API compositional. This is
possible without any fancy changes to IPC mechanisms. Other areas (such as
DDF) would greatly benefit from this simple improvement.


Simple, non-elegant, non-generic server-relativity mechanism is possible. 
The proper generic mechanism for server-relative configuration and
configuration change notification is dependent on co

[HelenOS-devel] Minutes of HelenOS online meeting 2023-09-14

2023-09-15 Thread Jiri Svoboda

Hi,




thanks for attending the meeting! Please find the minutes below.




Cheers,

Jiri





Minutes of HelenOS online meeting 2023-09-14

Attendees:
  JJ - Jakub Jermář
  VH - Vojěch Horký
  JS - Jiří Svoboda

Scribe: JS

Camp planning
-
  - everybody agrees that if dates are fixed in advance, they will
    adjust their holiday plans accordingly
  - JJ will make plans/dates at beginning CY 2024

Github 2FA rollout
--
  - Github is starting to require 2FA (SMS, TOTP, ..)
  - JJ enabled SMS authentication and seems to work fine

ci.helenos.org issues
-
  - all test failed in last build because they did not OCR the prompt
correctly
 VH: should be already fixed in git
  - stopped updating in May
 - looks like this is because the server was moved and this changed ssh
keys
 VH: will contact Martin about this

SIF design discussion
-
  - JS: Asks VH for hist input on SIF design
  - VH: remind me, what is SIF?
  - JS: It is an API for a server to maintain configuration in a (binary)
DB,
    although it lacks proper implementation.
  - VH: If the DB is stored in a binary format, this prevents it from being
    easily revision controlled by a tool such as Ansible
  - JS: THX for your input! Some thoughts:
    - a DB is not necessarily needed unless the configuration is really
large,
  a plain storage format could work as well
    - a DB could use text or text-like format to be compatible with RCS

GCC update discussion
=
  http://www.helenos.org/ticket/834
  https://github.com/HelenOS/helenos/pull/226

  JJ : As far as I know only Itanium and ARM are broken
    ARM: problem with soft vs. hardfloat and libgcc
 -mgeneral-regs-only to force GCC not to use FP registers
 -mabi=soft/softp - use the right one
 - VH&JS seem to know what to do
    Itanium : broken atm.
  JS : Could integrate if we then focus to fix it afterwards
    AI: JS to test BeagleBoard

Progress updates

JS:
 - would like to remind JZr : #859 Build with Detailed kernel logging
enabled fails
 - some small wiki maintenance (noticed: New theme)
  (- syc arrays, array & struct initializers)
  - Split drop-down menu into drop down & menu
  - Allow menu entries to be disabled
  - System menu WIP

VH:
  - student working on packet capture thesis
  - struggling with GCC update (see above)

JJ:
  Worked on GCC update
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS online developer meeting Tursday 2023-09-14 @ 21:30 GMT+0200

2023-09-13 Thread Jiri Svoboda

Hi everyone,




I would like to invite you to our regular online meeting. It is happening 
tomorrow, Thursday, 2023-09-14 at 21:30 CEST (GMT+0200).




We will discuss current progress, issues and so on. Some possible topics of
interest, apart from progress updates, include:

 - Github 2FA rollout


 - plans for HelenOS camp





If you don't know if you are in the participant list, please check your 
Google Calendar. If you'd like to join, but are not listed as participant,
please let me know.





See you there!
Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of HelenOS online meeting 2023-08-10

2023-08-11 Thread Jiri Svoboda
Minutes of HelenOS online meeting 2023-08-10


Attendees:
  - JZr - Jiří Zárevúcky
  - JS - Jiří Svoboda

Scribe: JS

Round table
===

JS
--
- Closed PR #224 (Taskbar edit and new Application launcher)
- ticket #859
   discussed with JZr, assigned to him
- DOSMBoot - mainlining, status
   - Pushed static memory map to github
   - When I try to load modules, some are corrupted
   - Does it make sense to integrate to master even if does not work fully?
(JZr: probably yes)
- Syc
   - Lot of progress lately: struct, union, enum, constant expressions
   - Demo: strict enums & strict truth type
- Display Configuration utility
   - Fixing bugs and small things
   - Fixed window switching in display server
- Plans for near future: Start Menu, VirtKVM

JZr
---
- Not much progress, focusing on upcoming exams
- Will look into #859
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS online developer meeting Tursday 2023-08-10 @ 21:30 GMT+0200

2023-08-09 Thread Jiri Svoboda

Hi everyone,




I would like to invite you to our (semi)regular online meeting. It is
happening tomorrow, Thursday, 2023-08-10 at 21:30 CEST (GMT+0200).




It's great to see the recent increased project activity - thanks to everyone
for their work. There is definitely a lot of material to discuss. We will be
thrilled to have Vhotspur and JZr they can make it as well.





See you there!
Cheers,

Jiri




PS: If you are not on the guest list, please let me know. If the date does
not work for you, maybe we can figure out something else, although it's 
always challenging during summer holidays.


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] HelenOS Camp 2024

2023-07-26 Thread Jiri Svoboda
+1 :-D
-- Původní e-mail --
Od: Jiří Zárevúcky 
Komu: HelenOS development mailing list 
Datum: 26. 7. 2023 11:11:18
Předmět: Re: [HelenOS-devel] HelenOS Camp 2024
"
Yes! :)



On Wed, Jul 26, 2023, 11:09 AM Jakub Jermář mailto:ja...@jermar.eu)> wrote:

"Hi,

the last HelenOS Camp took place in 2019. If there is enough interest,
I'd like to organize another one in the summer season of 2024 somewhere
in the Czech mountainous countryside (i.e. the good old HelenOS Camp).

Let me know if you'd like to attend and whether we should start
organizing this.

Jakub


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz(mailto:HelenOS-devel@lists.modry.cz)
http://lists.modry.cz/listinfo/helenos-devel
(http://lists.modry.cz/listinfo/helenos-devel)
"
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] DOSMBoot teaser video

2023-06-02 Thread Jiri Svoboda
Hi Martin,
"Just out of curiosity, why do you use Borland C++? AFAIK it is still "
If I remember correctly, my main idea was that I might make good use of 
Turbo Debugger (and I think I did at one point). Plus I really enjoy Borland
IDE and I am very familiar with it & the compiler.


"Would Open Watcom not work for you (if you need to generate 16-bit
code)? Or even DJGPP (if you can live with a DOS extender)? "
My plan from the get-go was to switch to OpenWatcom once the bulk of
development is done. This should be easy, I don't think it uses any Borland-
specific functionality (if there is such a thing).




So I will switch to OpenWatcom before I will integrate this into HelenOS. My
idea is that the bootloader source would live in HelenOS source tree, plus
we will provide a pre-compiled binary within the source tree, as we do with
GRUB.





DJGPP would not be an option, the C code must run in real mode. I don't 
think there is a way of guaranteeing that protected mode DOS code would not
interfere with the memory areas where we want to load the kernel.





Best regards,

Jiri




"


M.D.

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] DOSMBoot teaser video

2023-06-01 Thread Jiri Svoboda

Hi all,




I have finally picked up work on DOSMBoot! Hurray!




http://jiri-svoboda.blogspot.com/2023/06/dosmboot-teaser.html




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS online meeting 2023-04-14

2023-04-13 Thread Jiri Svoboda

Hi,




thanks to those who attended our online meeting. Please find the minutes 
below.


Cheers,

Jiri





Minutes of the HelenOS online meeting 2023-04-14

Attendees:
  JJ - Jakub Jermář
  JS - Jiří Svoboda
  JZr - Jiří Zárevúcky

Scribe:
  JS

Round table
===
  JJ - discussion of safety issues with suspicious 80's computer PSUs
  JZr - thinking about simplification of thread lockning
  - leverage the fact that a thread cannot run on two CPUs at the same
time
  JS - UI display configuration utility nearly ready for merging (pending
unit tests)
   - includes new stock dialog (selection dialog)
   - will need to follow up with improvements to window switching, etc.
   - this is a good stepping stone towards Start menu editor
 - Making good progress on Syc towards it being a functional compiler
   - delivering it from Sycek harbour will make sense once it includes
assembly/link stage
 and thus can produce tape files for GZX
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS online developer meeting - 2023-04-13

2023-04-13 Thread Jiri Svoboda

Hi all,




a reminder that our regular online meeting is happening tonight at 21:30 GMT
+0200. I realized that the February meeting was not periodic, so I
duplicated it into a new meeting occuring periodically on the second
thursday. You should have recieved an invitation. If not, please check your
google calendar and contact me if there is any issue or if you'd like to 
join but you are not in the participant list.





Looking forward to meeting you tonight and discussing latest developments!




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Open ticket #629

2023-03-12 Thread Jiri Svoboda

Hi Natalia,




AFAIK nobody is working on this, so if you'd like to give it a try, go
ahead.




And while I would certainly not like to discourage you, this looks like 
something way more complicated than what I would expect a first-time
contributor to be able to accomplish.




Actually I'm not sure exactly how much work this will be, because I haven't
given though to the design yet.

So what needs to be done here:

 - you need to have an understanding of the overall network stack design

 - you need to come up with a design for how the capture mechanism will work
(i.e. where the capturing will occur, how it will transport/store/write the
data)

  - implement in compliance with all our coding style and best practices as
well as advice from the team




Of course if you'd like just to experiment and play around, you can do it 
anyway you like, just it might not be integrated to our codebase, perhaps it
would be just used as an inspiration. - Even that can be fun, note that, and
most first time contributors have a hard time understanding that, for a new
contributor getting from zero to a working prototype is usually much easier
than getting from a working prototype to something that can be integrated to
the codebase.




Best regards,

Jiri




-- Původní e-mail --
Od: Nataliia Korop 
Komu: helenos-devel@lists.modry.cz 
Datum: 11. 3. 2023 17:26:51
Předmět: [HelenOS-devel] Open ticket #629
"

Hello everyone,

I would like to contribute to developing HelenOS by implementing Network 
packet capturing. As far it is an open ticket #629 (http://www.helenos.org/
ticket/629). I would like to know if somebody is working on it at the
moment? If yes, please contact me and write about a stage are you at?

Thank you,

Natasha  

 ___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Progress update for Feb 2023

2023-03-02 Thread Jiri Svoboda

Hi,




since we basically ran out of time last hangout, I didn't have a chance to
provide update from my side, so here's some update from me:





Multi-seat



  - Multi-seat is fully implemented, can be configured using the command
line. I updated the wiki with documentation.





Added tab set control

===


  - allows splitting window content into multiple tabs to expand available
space (e.g. in a configuration window)




Ccheck

==

  - Added support for _Alignas() to ccheck - per JZr's request




Best regards,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of HelenOS online meeting 2023-02 (belated)

2023-03-02 Thread Jiri Svoboda

Hi,




here's the belated minutes of the last online meeting. Google hangouts
finally stopped working, so we had to switch to Google Meet.




Best regards,

Jiri





Minutes of HelenOS online meeting 2023-02
==

Attending:
  JJ - Jakub Jermář
  JS - Jiří Svoboda
  JZr - Jiří Zárevúcky
  MD - Martin Děcký

Scribe: JS

Round Table
===
JJ
     attempted to merge JZr's changes to IPCv2 branch
     Colin Parker's issues
     Page table entries - worked if memory < 4GB
        - with fix tests did not crash even if > 4GB mem
        - merged
     Multiproc spec colliding with boot module allocation
         - did not look more into it
JZr
    - simplification of threads/synchronization
    - good feedback overall
    - const discussion
    - 80 columns - should be heeded
    - macro ->static inline -> normal func - keep inline funcs
      to optimize non-SMP
    - deadlines overflowing
    - JJ: lost _waitq_wait with flags needed for IPCv2 syscall
    - found issue: "head" of 1 is too long in Helena typeface

    i8042 presence detection - could use SMBIOS
    Lazy FPU context switching discussion
        - side channel
        - change method or switch off by default?
MD
    rewrite custom mechanism to kernel symbols
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS 0.12.1 article on alt-f4.cz (in Czech)

2023-02-07 Thread Jiri Svoboda

Hi,




FYI stumbled upon this HelenOS 0.12.1 news article in Czech on some site 
called ALT-F4.




https://www.alt-f4.cz/helenos-0-12-1




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] ticket 470 - Mac Mini boot issues

2023-02-01 Thread Jiri Svoboda

Hi Colin,



> Unfortunately I don't have access to the serial console. Was kconsole 
designed to work with USB? I think maybe not, unfortunately.

You are right, there is no USB driver in the kernel. Bringing up a system 
that only has USB devices can be a problem.



> BTW, I think the XHCI issue is related to interrupt claims. On the Mac 
Mini, "cat /log/pciintel" shows literally all devices assigned IRQ 0. I 
suppose MSI is not used. I am thinking maybe either XHCI driver should poll
before timing out, or more sophisticated interrupt handling should be done
(reassigning IRQ numbers at boot or using MSI).

AFAIK HelenOS does not assign IRQs. It just reads the assignments from the
PCI configuration space. It thus relies on the firmware to do this. It's 
probably something that needs to be implemented. I think that even BIOS 
perhaps assigns IRQs only if you do not enable "PnP-aware operating system"
and even if you configure to have a legacy OS, it might not assign all IRQs.
I think I might have run afoul of this on my AMD Phenom system or my laptop
where it did not assign IRQs to some of the devices (such as USB host
controllers).





Cheers,

Jiri





" ___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Multi-seat support now complete

2023-01-22 Thread Jiri Svoboda

Hi,




just to note that multi-seat support is now fully working. Currently it can
be configured using the command line (next step is to add a UI configuration
for it).




You can find basic documentation here: http://www.helenos.org/wiki/
UsersGuide/MultiSeat




Let me know if you have questions or find some issues.


Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2023-01-12

2023-01-13 Thread Jiri Svoboda
Minutes of the HelenOS hangout 2023-01-12
=

Attending:
  JJ - Jakub Jermář
  JS - Jiří Svoboda
  JZr - Jiří Zarevúcky

Scribe: JS

JJ
  - released 0.12.1 Cathode (thanks again!)
JZr
  - implemented kernel timer improvement (JJ merged)
  - no need to periodically update timers
  - TODO: change all timer APIs to deadlines?
  - PR: SPDX license tags
 discussion
 no current agreement to implement these
  - finds it useful to be reminded 1 d before hangout
JS
  - window minimization
  - highlight active window(s) in taskbar
  - window switching fixes
  - protocol library fixes (these could be detected by static analysis :-,)
  - Multi-seat support (WIP)
 - multiple mice and keyboards can be used with a single desktop
 - Q: What is a seat?
 - A: A seat object consists of a cursor and a set of associated devices 
(mice, keyboards)
 - Q: What are the actual use cases for multiple seats?
 - A:
   1. Multiple users sharing a big screen (e.g. conference room, 
mission control room)
   2. Multi-monitor setup - similar to multi-head, but allowing windows 
to be occasionally moved from one monitor to another.
   3. When sharing desktop (e.g. with tech support) - better to see a 
new cursor appear, than to have your own cursor hijacked
   4. A single user can work with two windows alternately by using two 
keyboards instead of switching focus

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2022-12-08

2022-12-09 Thread Jiri Svoboda
Minutes of the HelenOS hangout 2022-12-08
=
Attendees:
  JJ - Jakub Jermář
  JS - Jiří Svoboda

Scribe:
  JS

JS
  - Created ReleaseNotes/0.12.1 and moved content from ReleaseNotes/
Mainline,
    added screenshots
  - Maximized windows are no longer partially obscured by task bar
  - Text abbreviation
  - Fixed rendering of small buttons failing because of abbreviation
  - Fixed scrollbar reporting out-of-range positions which was causing
assertion failures
 
Upcoming release action items:
  - Finalize code name (JJ)
  - Test BeagleBoard XM, if possible (JS)
  - Prepare What's new screencast (JS)
  - Build / test / release (JJ)
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2022-11-16

2022-11-17 Thread Jiri Svoboda
Minutes of the HelenOS hangout 2022-11-16
=
Attendees:
  - JJ - Jakub Jermář
  - JS - Jiří Svoboda

Scribe: JS

Round table:
  - JJ
    - looked at his IPCv2 code to refresh memory
    - rebased to latest master, all test pass
  - JS
    - pushed Task bar to master, always on top
    - updated http://www.helenos.org/wiki/UsersGuide/RunningInVirtualBox
    - WIP text abbreviation: when window caption does not fit title bar /
window button,
  drop characters at the end and replace with ellipsis (...)

HelenOS release
  - Release 0.12.1 before end of the year
  - JJ agreed to be the RM for 0.12.1

Agreed release timeline for HelenOS 0.12.1
  - code freeze 2022-11-30
  - what's new video due 2022-12-07 (JS)
  - release: 1st half of December 2022
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] VirtualBox guide + planning a release

2022-11-14 Thread Jiri Svoboda

Hi,




I updated the virtual box guide at


http://www.helenos.org/wiki/UsersGuide/RunningInVirtualBox




based on recent fixes and feedback from the community. The text expects 
there to be an 0.12..1 release (i.e. this year).




I think we should start planning to release in December. I think we have 
enough material for a release. I'd like to dive into some new and exciting
stuff in the near future and we don't want to overload a release with too 
much new exciting content, do we? ^_^




I didn't really have the time for a hangout last week so I've let it pass,
but what about having a hangout some time this week?




Best regards,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Task Bar

2022-11-14 Thread Jiri Svoboda

Hi,




the task bar is now available in HelenOS master and it is started by default
in desktop mode. It dsplays the clock updating every second (and thus also
serves as a heartbeat indicator) and it allows switching the active window.




There is clearly a lot of work left. Namely, maximized windows should avoid
the task bar area (currently they maximize to the entire screen and are 
partially obscured), dealing with more windows than we can fit, adding a 
start menu. Therefore work continues.




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19

2022-11-07 Thread Jiri Svoboda

Also, if you are looking for an 64-bit ARM board with a reasonable price, 
you should note that the Raspberry Pi line uses 64-bit ARM processors since
Pi 3. (HelenOS currently supports the 32-bit only Pi 1).




-Jiri

-- Původní e-mail --
Od: Jiri Svoboda 
Komu: HelenOS development mailing list 
Datum: 5. 11. 2022 15:23:35
Předmět: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19
"Hi Jerry,




> Thanks. All of my testing/experimentation uses VBox. On which note would
just like to confirm that I’ve built and run the AMD64 variant from the head
> of the Github repo. Kudos to all for a painless experience.
Glad to hear that.


> All of which raises many new questions re booting, configuration,
operation etc. Is this the best forum or is IRC preferred?

 Yup, this is the best communication channel.



> FWIW My (currently academic) interest is in establishing the effort/tasks
required to run HelenOS on a commodity ARM64 board.  i.e. as a headless
embedded networked system, targeting inexpensive SoCs like the AllWinner H5/
H6.

We can boot on HiKey960, which is a 64-bit ARM board. http://www.helenos.
org/wiki/HiKey960
AFAIK the port is limited to a serial console and a single processor.

This puts you in a pretty good position if you want to add support for
another 64-bit ARM board. However, ARM architecture tends to be very
heterogenous. It may be necessary to do some (un-trivial) tweaks in the 
memory management area (big differences between different ARM
implementations) and so on.

If you want network connectivity, the network adapter driver will be a
project onto itself.

If you are trying to determine which board to use, you should make sure that
the CPU/board you choose has all the documentation you need avalable (memory
subsystem, I/O devices, etc). For example, it would be a bummer if (based on
the goals you stated) made the system boot on a board and then found out 
that there is no documentation available for the Ethernet adapter so there
is no way to write a driver for it.

Cheers,
Jiri

-- Původní e-mail --
Od: g...@novadsp.com
Komu: 'HelenOS development mailing list' 
Datum: 3. 11. 2022 15:12:02
Předmět: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19
"

Hello Jiri,

 

Thanks. All of my testing/experimentation uses VBox. On which note would 
just like to confirm that I’ve built and run the AMD64 variant from the head
of the Github repo. Kudos to all for a painless experience.

 

All of which raises many new questions re booting, configuration, operation
etc. Is this the best forum or is IRC preferred?

 

FWIW My (currently academic) interest is in establishing the effort/tasks 
required to run HelenOS on a commodity ARM64 board.  i.e. as a headless
embedded networked system, targeting inexpensive SoCs like the AllWinner H5/
H6.

 

BR

 

Jerry.

 



 From: HelenOS-devel  On Behalf Of 
 Jiri Svoboda
 Sent: 31 October 2022 15:31
 To: HelenOS development mailing list 
 Subject: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19



 


Hi Jerry,



 



as you correctly wrote in your next message, using USB Tablet is the right
way to get pointer integration. I was planning to write a wiki article on 
running in VirtualBox before the next official release. Probably should do
that sooner.



 



At the moment there is no command to perform  graceful shutdown. It's
something I have on my mind as I would like to add that functionality to the
task bar, too.



 



Normally you're running a live ISO image and all you need to do is to remove
power from the (virtual) machine. If you mounted some file systems, then 
you'd need to unmount those first manually to prevent them from being
corrupted.



 



if you were lucky enough to install the OS on the first hard drive in Qemu
(just tested and does not seem to work in the latest git revision), then 
you'd want to unmount the system volume before powering off ("vol eject /
w").



 



Cheers,



Jiri



 


-- Původní e-mail --
Od: g...@novadsp.com(mailto:g...@novadsp.com)
Komu: 'HelenOS development mailing list' mailto:helenos-devel@lists.modry.cz)>
Datum: 31. 10. 2022 15:05:13
Předmět: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19


"

Excellent, that works with a bridged adapter.

 

A couple of dumb questions:

 

   1. How to power off from the terminal/shell?
   2. Is any VBox pointer device integration operational? PS/2 Mouse needs
   Ctrl in VBox for release.


 

Thanks again -

 



 From: HelenOS-devel mailto:helenos-devel-boun...@lists.modry.cz)> On Behalf Of Jiri Svoboda
 Sent: 31 October 2022 09:45
 To: HelenOS development mailing list mailto:helenos-devel@lists.modry.cz)>
 Subject: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19



 


Hi Jerry,



 



actually, yes. You can find latest automatic builds on http//ci.helenos.org/



Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19

2022-11-05 Thread Jiri Svoboda
Hi Jerry,




> Thanks. All of my testing/experimentation uses VBox. On which note would
just like to confirm that I’ve built and run the AMD64 variant from the head
> of the Github repo. Kudos to all for a painless experience.
Glad to hear that.


> All of which raises many new questions re booting, configuration,
operation etc. Is this the best forum or is IRC preferred?

 Yup, this is the best communication channel.



> FWIW My (currently academic) interest is in establishing the effort/tasks
required to run HelenOS on a commodity ARM64 board.  i.e. as a headless
embedded networked system, targeting inexpensive SoCs like the AllWinner H5/
H6.

We can boot on HiKey960, which is a 64-bit ARM board. http://www.helenos.
org/wiki/HiKey960
AFAIK the port is limited to a serial console and a single processor.

This puts you in a pretty good position if you want to add support for
another 64-bit ARM board. However, ARM architecture tends to be very
heterogenous. It may be necessary to do some (un-trivial) tweaks in the 
memory management area (big differences between different ARM
implementations) and so on.

If you want network connectivity, the network adapter driver will be a
project onto itself.

If you are trying to determine which board to use, you should make sure that
the CPU/board you choose has all the documentation you need avalable (memory
subsystem, I/O devices, etc). For example, it would be a bummer if (based on
the goals you stated) made the system boot on a board and then found out 
that there is no documentation available for the Ethernet adapter so there
is no way to write a driver for it.

Cheers,
Jiri

-- Původní e-mail --
Od: g...@novadsp.com
Komu: 'HelenOS development mailing list' 
Datum: 3. 11. 2022 15:12:02
Předmět: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19
"

Hello Jiri,

 

Thanks. All of my testing/experimentation uses VBox. On which note would 
just like to confirm that I’ve built and run the AMD64 variant from the head
of the Github repo. Kudos to all for a painless experience.

 

All of which raises many new questions re booting, configuration, operation
etc. Is this the best forum or is IRC preferred?

 

FWIW My (currently academic) interest is in establishing the effort/tasks 
required to run HelenOS on a commodity ARM64 board.  i.e. as a headless
embedded networked system, targeting inexpensive SoCs like the AllWinner H5/
H6.

 

BR

 

Jerry.

 



 From: HelenOS-devel  On Behalf Of 
 Jiri Svoboda
 Sent: 31 October 2022 15:31
 To: HelenOS development mailing list 
 Subject: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19



 


Hi Jerry,



 



as you correctly wrote in your next message, using USB Tablet is the right
way to get pointer integration. I was planning to write a wiki article on 
running in VirtualBox before the next official release. Probably should do
that sooner.



 



At the moment there is no command to perform  graceful shutdown. It's
something I have on my mind as I would like to add that functionality to the
task bar, too.



 



Normally you're running a live ISO image and all you need to do is to remove
power from the (virtual) machine. If you mounted some file systems, then 
you'd need to unmount those first manually to prevent them from being
corrupted.



 



if you were lucky enough to install the OS on the first hard drive in Qemu
(just tested and does not seem to work in the latest git revision), then 
you'd want to unmount the system volume before powering off ("vol eject /
w").



 



Cheers,



Jiri



 


-- Původní e-mail --
Od: g...@novadsp.com(mailto:g...@novadsp.com)
Komu: 'HelenOS development mailing list' mailto:helenos-devel@lists.modry.cz)>
Datum: 31. 10. 2022 15:05:13
Předmět: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19


"

Excellent, that works with a bridged adapter.

 

A couple of dumb questions:

 

   1. How to power off from the terminal/shell?
   2. Is any VBox pointer device integration operational? PS/2 Mouse needs
   Ctrl in VBox for release.


 

Thanks again -

 



 From: HelenOS-devel mailto:helenos-devel-boun...@lists.modry.cz)> On Behalf Of Jiri Svoboda
 Sent: 31 October 2022 09:45
 To: HelenOS development mailing list mailto:helenos-devel@lists.modry.cz)>
 Subject: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19



 


Hi Jerry,



 



actually, yes. You can find latest automatic builds on http//ci.helenos.org/



 



In the HelenOS table you can find Architecture: amd64 and click on "HelenOS
boot image" link and you will be able to download the ISO.



 



The link to the amd64 ISO image for the current latest build is http://ci.
helenos.org/build-558/amd64/helenos-amd64.iso
(http://ci.helenos.org/build-558/amd64/helenos-amd64.iso)



I've tested this image specifically and it works fine in VirtualBox.




You 

Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19

2022-10-31 Thread Jiri Svoboda

Hi Jerry,




as you correctly wrote in your next message, using USB Tablet is the right
way to get pointer integration. I was planning to write a wiki article on 
running in VirtualBox before the next official release. Probably should do
that sooner.





At the moment there is no command to perform  graceful shutdown. It's
something I have on my mind as I would like to add that functionality to the
task bar, too.




Normally you're running a live ISO image and all you need to do is to remove
power from the (virtual) machine. If you mounted some file systems, then 
you'd need to unmount those first manually to prevent them from being
corrupted.




if you were lucky enough to install the OS on the first hard drive in Qemu
(just tested and does not seem to work in the latest git revision), then 
you'd want to unmount the system volume before powering off ("vol eject /
w").




Cheers,

Jiri




-- Původní e-mail --
Od: g...@novadsp.com
Komu: 'HelenOS development mailing list' 
Datum: 31. 10. 2022 15:05:13
Předmět: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19
"

Excellent, that works with a bridged adapter.

 

A couple of dumb questions:

 

   1. How to power off from the terminal/shell?
   2. Is any VBox pointer device integration operational? PS/2 Mouse needs
   Ctrl in VBox for release.


 

Thanks again -

 



 From: HelenOS-devel  On Behalf Of 
 Jiri Svoboda
 Sent: 31 October 2022 09:45
 To: HelenOS development mailing list 
 Subject: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19



 


Hi Jerry,



 



actually, yes. You can find latest automatic builds on http//ci.helenos.org/



 



In the HelenOS table you can find Architecture: amd64 and click on "HelenOS
boot image" link and you will be able to download the ISO.



 



The link to the amd64 ISO image for the current latest build is http://ci.
helenos.org/build-558/amd64/helenos-amd64.iso
(http://ci.helenos.org/build-558/amd64/helenos-amd64.iso)



I've tested this image specifically and it works fine in VirtualBox.




You need to configure your vitual machine correctly, though, as HelenOS does
not support the default network and audio device selected by VirtualBox for
"Other" operating system.



 



For network device select Intel PRO/1000 MT Server or Desktop.



For audio device select Intel HD Audio (Soundblaster 16 should also work, 
but NOT AC97).



 



Cheers,



Jiri



 


-- Původní e-mail --
Od: g...@novadsp.com(mailto:g...@novadsp.com)
Komu: 'HelenOS development mailing list' mailto:helenos-devel@lists.modry.cz)>
Datum: 29. 10. 2022 16:32:52
Předmět: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19


"

Hello all.

 

Great news re VBox. Is there a new .ISO release that can be quickly tested
on x64/VBox (or even VMWare?)

 

Thx++

 

Jerry.

 



 From: HelenOS-devel mailto:helenos-devel-boun...@lists.modry.cz)> On Behalf Of Jiri Svoboda
 Sent: 24 October 2022 19:20
 To: helenos-devel@lists.modry.cz(mailto:helenos-devel@lists.modry.cz)
 Subject: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19



 

Minutes of the HelenOS hangout 2022-10-19
=
Attendees:
  JJ - Jakub Jermář
  JSv - Jiří Svoboda

Scribe:
  JSv

Round table
===
JJ
  - Wondering if ticket #752 (hound crashes on a dual-CPU system) has been
fixed by changeset
    2fbd49c61404ed7f2e7f36f65d920ef81281a58e (Audio synk needs locking)
    Editor's note: Yes, it is. Closed.
JSv
  - HelenOS works now OK in VirtualBox - fixed network and audio problems
  - Wanted to implement parameters negotiation in HD Audio driver, but ran
afoul Hound / audio device interface limitations
  - Working on UI task bar (see https://github.com/jxsvoboda/helenos
(https://github.com/jxsvoboda/helenos))
  - Contemplating limitations of current audio architecture (e.g. http://
jiri-svoboda.blogspot.com/2022/09/problems-with-hound-audio-architecture.
html
(http://jiri-svoboda.blogspot.com/2022/09/problems-with-hound-audio-architecture.html)
)


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz(mailto:HelenOS-devel@lists.modry.cz)
http://lists.modry.cz/listinfo/helenos-devel
(http://lists.modry.cz/listinfo/helenos-devel)
"
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19

2022-10-31 Thread Jiri Svoboda

Hi Jerry,




actually, yes. You can find latest automatic builds on http//ci.helenos.org/




In the HelenOS table you can find Architecture: amd64 and click on "HelenOS
boot image" link and you will be able to download the ISO.




The link to the amd64 ISO image for the current latest build is http://ci.
helenos.org/build-558/amd64/helenos-amd64.iso

I've tested this image specifically and it works fine in VirtualBox.


You need to configure your vitual machine correctly, though, as HelenOS does
not support the default network and audio device selected by VirtualBox for
"Other" operating system.




For network device select Intel PRO/1000 MT Server or Desktop.

For audio device select Intel HD Audio (Soundblaster 16 should also work, 
but NOT AC97).




Cheers,

Jiri




-- Původní e-mail --
Od: g...@novadsp.com
Komu: 'HelenOS development mailing list' 
Datum: 29. 10. 2022 16:32:52
Předmět: Re: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19
"

Hello all.

 

Great news re VBox. Is there a new .ISO release that can be quickly tested
on x64/VBox (or even VMWare?)

 

Thx++

 

Jerry.

 



 From: HelenOS-devel  On Behalf Of 
 Jiri Svoboda
 Sent: 24 October 2022 19:20
 To: helenos-devel@lists.modry.cz
 Subject: [HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19



 

Minutes of the HelenOS hangout 2022-10-19
=
Attendees:
  JJ - Jakub Jermář
  JSv - Jiří Svoboda

Scribe:
  JSv

Round table
===
JJ
  - Wondering if ticket #752 (hound crashes on a dual-CPU system) has been
fixed by changeset
    2fbd49c61404ed7f2e7f36f65d920ef81281a58e (Audio synk needs locking)
    Editor's note: Yes, it is. Closed.
JSv
  - HelenOS works now OK in VirtualBox - fixed network and audio problems
  - Wanted to implement parameters negotiation in HD Audio driver, but ran
afoul Hound / audio device interface limitations
  - Working on UI task bar (see https://github.com/jxsvoboda/helenos
(https://github.com/jxsvoboda/helenos))
  - Contemplating limitations of current audio architecture (e.g. http://
jiri-svoboda.blogspot.com/2022/09/problems-with-hound-audio-architecture.
html
(http://jiri-svoboda.blogspot.com/2022/09/problems-with-hound-audio-architecture.html)
)

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Working on the Task Bar for HelenOS (video)

2022-10-27 Thread Jiri Svoboda

http://jiri-svoboda.blogspot.com/2022/10/working-on-task-bar-for-helenos.
html




-Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2022-10-19

2022-10-24 Thread Jiri Svoboda
Minutes of the HelenOS hangout 2022-10-19
=
Attendees:
  JJ - Jakub Jermář
  JSv - Jiří Svoboda

Scribe:
  JSv

Round table
===
JJ
  - Wondering if ticket #752 (hound crashes on a dual-CPU system) has been
fixed by changeset
    2fbd49c61404ed7f2e7f36f65d920ef81281a58e (Audio synk needs locking)
    Editor's note: Yes, it is. Closed.
JSv
  - HelenOS works now OK in VirtualBox - fixed network and audio problems
  - Wanted to implement parameters negotiation in HD Audio driver, but ran
afoul Hound / audio device interface limitations
  - Working on UI task bar (see https://github.com/jxsvoboda/helenos)
  - Contemplating limitations of current audio architecture (e.g. http://
jiri-svoboda.blogspot.com/2022/09/problems-with-hound-audio-architecture.
html)
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Activity report (March - September 2022)

2022-09-22 Thread Jiri Svoboda

Hi folks,




hope you are all doing well!




Looking through the mailing list I can see the last meeting minutes are from
March(!). Not sure why that is. I missed organizing the last couple of
hangouts, because I always remembred just too late that it is already second
Thursday of the month - sorry about that.




This all might lead to the impression that nothing is happening. That's 
certainly not the case. So I wrote up a summary of my activity since March.
Here it is:




* Alt-key menu activation
* Scrollbar


* Custom button decorations (e.g. scrollbar arrows, X for closing the
window)

* Memory bugs fixed in libui

* File list control

* Navigator ported to file list control and added scrollbars


* Fixed networking, keyboard and audio in VirtualBox




So now, among others, HelenOS works great in VirtualBox both with the right
network device configuration and with either SB or HD Audio.




While working on VirtualBox I've found out that HD Audio driver does not 
report/set rates/formats and that lead to a deep dive into our audio stack,
for details please see this blog post:



http://jiri-svoboda.blogspot.com/2022/09/problems-with-hound-audio-
architecture.html


And admittedly over the summer holidays I've been working mostly on Syc, 
rather than HelenOS, but fear not it is about time for a context switch ^_^.
Even this project looks like a tangent to HelenOS (and it most certainly 
is), it's much more related to HelenOS than you might think. I'm planning to
write a little bit about that (hopefully) soon. Stay tuned.





As for short my short-term plans: Even tough Navigator needs quite a bit of
work to become a real file manager (as opposed to just browser), as the next
step I plan to work on a task bar. That will be certainly an interesting and
non-trivial project. For example, to show a list of open windows (and
possibly allow switching between them), we need to add some kind of 'window
management' interface to Display server.




Talk to you again soon!




Cheers,

Jiri

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Fwd: Re: Work with PCI registers

2022-05-10 Thread Jiri Svoboda

Not sure if Serhii is in the ML, so I'm resending this with direct CC.



-- Původní e-mail --
Od: Jiri Svoboda 
Komu: HelenOS development mailing list 
Datum: 10. 5. 2022 15:44:58
Předmět: Re: [HelenOS-devel] Work with PCI registers
"
Hi Serhii,




mapping the registers would be typically done in the driver's dev_add entry
point.

  * get the parent session using ddf_dev_parent_sess_get()

  * get list of HW resources (hw_res_list_parsed_init() / hw_res_get_list_
parsed()

 - memory ranges, I/O ranges, interrupts

  * map registers using pio_enable()

  * access registers using pio_read_x() / pio_write_x()





Handling interrupts:

    * prepare IRQ pseudocode and handler function


    * register_interrupt_handler()

    * hw_res_enable_interrupt()




Handling DMA

   * dmamem_map_anonymous() / dmamem_unmap_anonymous()




If you'd like to see an example how this is done, you can check, for
example:

*  uspace/drv/audio/hdaudio/hdaudio.c : hda_dev_add()


*   uspace/drv/nic/e1k/e1k.c : e1000_dev_add()



Hope this helps,

Jiri




-- Původní e-mail --
Od: Serhii Sakhno 
Komu: helenos-devel@lists.modry.cz
Datum: 9. 5. 2022 10:38:21
Předmět: [HelenOS-devel] Work with PCI registers
"I read an article on Wiki about writing drivers and checked existing
drivers, but I did not understand some things with PCI/PCIe buses. How
to map needed registers?



Regards,

Serhii


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
""___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Work with PCI registers

2022-05-10 Thread Jiri Svoboda

Hi Serhii,




mapping the registers would be typically done in the driver's dev_add entry
point.

  * get the parent session using ddf_dev_parent_sess_get()

  * get list of HW resources (hw_res_list_parsed_init() / hw_res_get_list_
parsed()

 - memory ranges, I/O ranges, interrupts

  * map registers using pio_enable()

  * access registers using pio_read_x() / pio_write_x()





Handling interrupts:

    * prepare IRQ pseudocode and handler function


    * register_interrupt_handler()

    * hw_res_enable_interrupt()




Handling DMA

   * dmamem_map_anonymous() / dmamem_unmap_anonymous()




If you'd like to see an example how this is done, you can check, for
example:

*  uspace/drv/audio/hdaudio/hdaudio.c : hda_dev_add()


*   uspace/drv/nic/e1k/e1k.c : e1000_dev_add()



Hope this helps,

Jiri




-- Původní e-mail --
Od: Serhii Sakhno 
Komu: helenos-devel@lists.modry.cz
Datum: 9. 5. 2022 10:38:21
Předmět: [HelenOS-devel] Work with PCI registers
"I read an article on Wiki about writing drivers and checked existing
drivers, but I did not understand some things with PCI/PCIe buses. How
to map needed registers?



Regards,

Serhii


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2022-03-10

2022-03-11 Thread Jiri Svoboda
Minutes of the HelenOS Hangout 2022-03-10
=
Attendance:
  JJ - Jakub Jermář
  JS - Jiří Svoboda

Scribe:
  JS

Round table:

JJ
==
  sun4u text console mode ew fix
  Fixed bug where entire ASID was unmapped instead of just the specified
range (#839)
 - Bug was introduced as part of non-identical memory support
JS
==
  Syc Compiler
    - Reporting progress on this C -> Z80 compiler living within Sycek
project
    - Use as checker for HelenOS in future
   - complementary to Ccheck, things that need deeper insight (thus
actual compilation)
   - examples of what could be done
  - order of declaration specifiers (int unsigned long) (already
implemented)
  - strict truth type (if (42) ...; int i = 3 < 2;) (in progress)
      - strict enum type (errno_t rc; if (rc == 0))
  - include what you use
  - etc.
    - Use as compiler for some specific CPU targets (Z80, 8086, ...)
  Networking in VirtualBox (#840)
    - fixed DHCP incorrectly setting ciaddr
    - still DNS not working and getting wrong DNS server address from DHCP
(and DHCP server not responding on the correct IP address 10.0.2.3)
  Menu accelerator keys
    - almost done
    - missing Alt+Key menu activation
    - need to set 'c' in keyboard events even when Alt is depressed
    - may need to fix applications that suppose that if c is set, modifiers
are not active
    EDIT: Now all done.
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2022-02-10

2022-02-11 Thread Jiri Svoboda
Minutes of the HelenOS hangout 2022-02-10
=
Attendance:
  JJ - Jakub Jermář
  JS - Jiří Svoboda

Scribe: JS

JJ
==
  #833 Tester malloc1 fails with -march=pentium4
    - was working on this, but accidentally fixed by JS
  Discussion of other known hang-like bugs on SPARC
  Tools/ew.py currently cannot start Sun4u in serial console mode (NOTE: JJ
fixed this since)
  Sun4u kernel console still missing Qemu keyboard support (JS needs to RC
bug in his prototype impl)

JS
==
  Fixed #831 With -M isapc graphical kernel console is not visible
    - RC: did not verify that fallback mode supports LFB
    - also a number of other checks were missing (mode is listed, get mode
attributes, flag: mode is supported, success code in AH)
  Fixed #824 (Graphical console output corrupt in resolutions greater than
1024x768)
    - output server computed size of screen as max(devices), starting at 128
x128
  Fixed #832 Editor displays corrupt text with user-space -march 486
    - editor was using memmove() on overlapping blocks
  Fixed #829 System deadlocks early in boot on ia32 with FPU lazy context
switching off
    - CR0.TS was being set in reverse
    - This "accidentally" fixed #833
  Now -M isapc / 486 is fully working again!
  Closed some bugs as duplicate
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2022-01-13

2022-01-14 Thread Jiri Svoboda
Minutes of the HelenOS hangout 2022-01-13
=
Attendees:
  JJ - Jakub Jermář
  JS - Jiří Svoboda

Scribe:
  JS

JJ
==
  * With sparc64/sun4u ew.py -nographic should produce a serial console (it
does not)
  * Likes ticket #833 (Tester malloc1 fails with -march=pentium4) and may
look into it
  * Thinks #833 et al could be related to #464 (FPU preserved registers not
preserved across fibril switches)
  * Observed sparc64/sun4u in graphical mode somethimes gets stuck during
boot

JSv
===
  * It was good that we had the What's new video available at the time of
release
  * We have a backlong of around 75 bugs. We should allot time to fixing
bugs and not let it grow. In fact, seems like we should be able to work 
through it and resolve (almost) all bugs, which would be great

  * Implemented kernel support for Qemu sun4u keyboard, but there is a bug,
if typing too fast, it gets stuck, so not commited yet
  * In order for sun4u kernel to support Sun and PC keyboard (Qemu), it
needs to do scancode translation (JJ is okay with that)
  * Bugs #848 (Sticking PS/2 mouse in Qemu, unless full-screen) and #849
(Cursor wrapping around the top of the screen in EGA console / Qemu) are 
bugs in Qemu and seem to have been fixed between 5.2.0 and 6.2.0 (or not 
reproduced in the new default config, anyway) so closed them
  * Closed bugs #812, #818, #819 as they were already fixed, just forgotten.
  * Menu can now be activated and controlled using F10, arrow keys, Enter,
Escape (next step is to support keyboard accelerators)
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS 0.11.2 (Kiev) released

2021-12-17 Thread Jiri Svoboda
Hi all!

HelenOS 0.11.2 (Kiev) has been released!

This release brings support for AArch64-based HiKey960 single-board
computer, brings a prototype version of Navigator, a panel-based file
manager, and improvements to the user interface, improvements to text mode
support and improved text editor.

More information can be found in the release notes:

http://www.helenos.org/wiki/ReleaseNotes/0.11.2

You can download HelenOS 0.11.2 from our download page:

http://www.helenos.org/wiki/Download#HelenOS0.11.2

Enjoy,
Jiri




PS: This release is code named in honor of Vsevolod V. Volkov of Kiev,
Ukraine, the creator of Volkov Commander


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2021-11-11

2021-11-11 Thread Jiri Svoboda
Minutes of the HelenOS hangout 2021-11-11
=

Attendees
-
  * JS - Jiri Svoboda
  * VK - Vit Kabele

Scribe: JS

Round Table
---

VK - Linux syscall emulation
 * Written as part of his master's thesis
 * It works, though he doesn't consider it 'production quality
 * Can run simple statically-linked binary (e.g. busybox)
 * Dynamically-linked executables not supported
 * https://git.kabele.me/vitkabele/helenos
 * Would like to eventually finish this and merge upstream, but not sure
when it will happen

JS
 * Preparing for 0.11.2 release
 * Unit test are all OK
 * During testing, ran into kernel test hangs on ia64/ski, sparc64/ultra and
sparc64/niagara; these can be reproduced with old releases, so it's not new
defects (in terms of code), so won't be considered stoppers for release
 * Still need to triage tickets, improve release notes with screenshots and
prepare What's new screencast
 * Still don't have the credentials for uploading to helenos.org

Free discussion
---
  * VK: Current activity level? Releases? JS: See github. Preparing for
second release this year.
  * VK: Project direction? Embedded use? JS: While we don't preclude server
and embedded, nobody is actively working in that area currently. I am
working mostly on desktop. [1]

Editor's notes:
1. HelenOS new, unique TUI capability makes it pretty pleasant to use with
servers and embedded systems that only have a serial console
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Results of pre-release testing so far - hikey960, riscv64 etc.

2021-11-01 Thread Jiri Svoboda

Hi,




I've been testing boot images in advance of 0.11.2 release and it's not 
looking all that good. Focusing just on images that should be able to run 
emulated:

* ia64/ski, msim, sparc64/niagara and sparc64/ultra all boot fine, but get
stuck in some (different) kernel test (either that or it takes waaay too 
long)

* mips32/malta-le, mips32/malta-be image is too big and fails to load

* riscv64 gets stuck after it writes "Booting the kernel..."

* arm32/raspberrypi .. upstream qemu does not support raspi1p, only raspi2(!
) when I run it as raspi2, it does not do anything

the other images that can be run in emulator work fine.




Can anyone give me insight on the state of riscv64 and raspberrypi? How 
about hikey960? Are these ports in state where it makes sense to release 
images? Should we release gta02 image if we know it hasn't been able to 
fully boot for a couple of years? (needs fixing!)




riscv64 is missing wiki documentation (http://www.helenos.org/wiki/
HardwareSupport)

hikey960 has just a stub written by me




Can I ask those knowledgable to document these new ports?




Thanks,

Jiri





Testing boot & kernel tests
===
  arm32/beagleboardxm - need to test HW
  arm32/beaglebone - will not test?
  arm32/gta02 - is it worthwhile to test (we know it takes too long to boot
and does not boot properly)
  arm32/raspberry pi emulation not working with mainstream qemu (no raspi1
ap, raspi2 does not seem to work)
  arm64/hikey960 - will not test
  ia64/i460GX .. will not test?
  ia64/ski .. seems to get stuck in some kernel memory test
  mips32/malta-be boot image too big!!! FAIL TO BOOT
  mips32/malta-le boot image too big!!! FAIL TO BOOT
  msim .. boots OK, kernel tests stuck in semaphore1(?)
  riscv64 .. stuck after "Booting the kernel..."
  sparc64/niagara .. stuck in kernel mapping1 test
  sparc64/ultra ... stuck in kernel memory test
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2021-10-14

2021-10-14 Thread Jiri Svoboda
Minutes of the HelenOS hangout 2021-10-14
=
Attendees:
  JJ - Jakub Jermář, JSv - Jiří Svoboda

Scribe:
  JSv

Release planning

  - Looks like we have enough new content to make 0.11.2 release later this
year (December)
  - JSv to fill the role of release manager for 0.11.2
  - Release notes should contain screenshots galore

Round table
---
JJ
  - Root caused build error with Meson 0.58.0 (and JZr fixed)
  - Appointed JSv as the release manager for 0.11.2 and briefed on the
release process
  - Seemed surprised to see other applications than Calculator running in
text mode

JSv
  - Ported text editor to libui - twice (lost the sources the first time,
see http://jiri-svoboda.blogspot.com/2021/09/oops-i-did-it-again.html)
  - Started work on file manager (https://github.com/jxsvoboda/helenos),
making good progress
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Hangout invitation (this Thursday)

2021-10-12 Thread Jiri Svoboda

Hi everybody,




I just sent an invitation for this week's hangout (Thursday, Oct 14 @ 21:30
CEST). If you haven't received an invitation and would like to join us, 
please let me know.




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] A letter for you

2021-09-29 Thread Jiri Svoboda

Hi folks,




Here's another video blog entry concerning the latest developments.




http://jiri-svoboda.blogspot.com/2021/09/a-letter-for-you.html




Enjoy,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Oops I did it again!

2021-09-20 Thread Jiri Svoboda

Hi,




we should all know the rules of how to safeguard our precious data. But do
we always follow them? If you have a couple of minutes, grab a coffee and 
read my blog.




http://jiri-svoboda.blogspot.com/2021/09/oops-i-did-it-again.html




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of HelenOS hangout 2021-09-09

2021-09-10 Thread Jiri Svoboda

Hi,




here's the minutes of yesterday's hangout. I was late so they are a little
sketchy. Please feel free to comment on anything I might have missed.


Best regards,

Jiri




Minutes of the HelenOS hangout 2021-09-09

Attending:
  Jakub Jermář
  Jiří Svoboda
  Maurizio Lombardi

Scribe:
  Jiří Svoboda

RPi 400 discussion:
  Jiří: RPi 400 looks interesting, it supports arm64 and is more of a
complete computer than a normal RPi (box, keyboard)
  Maurizio: Other RPi supports arm64, too
  Jakub: Has bought one for his kids, but not very satisfied with its
quality

Round table
===

Jakub:
  Wonders what problems could be resolved by MD's zone merge fix

Maurizio:
  Working on HelenOS support for some new board (sorry didn't quite catch
the name)

Jiří:
  DusXMT postponed his i810 plans
  We have a new student planning a thesis on Linux syscall emulation - plans
to join next hangout (October)
  Update on libui text-mode improvements
    - mostly usable in text mode now, including color and box-drawing
characters in EGA mode
    - still some work to do (keyboard-only control, movable windows)
  Started work on porting Edit to libui
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Hangout invites end up in spam folder

2021-09-06 Thread Jiri Svoboda

Hi,




sorry for sending multiple invites to the hangout this Thursday. I did it 
because seznam.cz's spam filter sent all my copies of the invitation to the
Spam folder and I thought it was not working.




Which is worrying. Other people could be affected too. If you did not
receive an invitation, please check your spam folder. If you still did not
receive an invitation and would like to join us, please let us know.




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Minutes of the HelenOS hangout 2021-08-12

2021-08-16 Thread Jiri Svoboda
Hi Jerry,

"Hello and thanks for the update. Has rpi support advanced beyond the Pi1 as
documented here http://www.helenos.org/wiki/RaspberryPi
(http://www.helenos.org/wiki/RaspberryPi)?"
Not that I'm aware of. Maurizio has recently made improvements to Raspberry
Pi video support. I think it's all Raspberry Pi 1 still, but maybe he will
correct me.



"
Re Intel 810 driver, would be utterly amazed if it ever found more than one
user.
"
Firstly, we're not in a position to tell anyone what they should be working
on. (How many people told us to go working on Linux instead. You smart
people understand OSes, but you are not improving Linux, heresy!) If
somebody has their pet HW they would like to be working on, who am I to tell
them otherwise? The only limitation is that if nobody else has the HW
available, then it's contributor will have to support it continually
(otherwise if we need to test changes and cannot, it might get removed from
the source).




> No wish at all here to be discouraging but would effort not be better 
spent on contemporary hardware support?

It might seem the obvious answer is "of course it's better to support
contemporary HW!", but it's actually not that obvious. While I am totally 
for improving contemporary HW support e.g. EAPIC / USB, modern e1000g etc 
(any takers?), contemporary harware is, by definition, a moving target. 
Especially graphics HW moves so fast, today's fresh new GPU is old history 2
years from now. At the current state of affairs we've no chance to keep up
with that pace.




For current HW, supporting virtualized HW makes most sense. If anything it
would make more sense to work on VirtIO GPU than on any particular current
actual GPU. Working on a historical PC graphics card might make more sense
than working on a contemporary graphics card.




Unlike most OSes that decidedly remove support for older HW we pride in 
keeping and improving that support. HelenOS can run on on 486-class ISA-
based PC and it is my intention to  improve that support for grandfather 486
-class PCs and beyond. We support Openmoko, iMac G4, Itanium.



The only downside of i810 is that it's not in emulators. Oh well. VGA driver
will be a great addition when it happens.

"



"
 
"



For the 100% committed though there may be some some suitable code in the 
FreeBSD/Haiku stacks …
"
That's a good point, it might be a good source of information (regardless of
the license the preference of original code still applies).




Cheers,

Jiri

"


Cheers,




Jerry.



Sent from my iPad


"On 16 Aug 2021, at 17:32, Jiri Svoboda  wrote:

"
"
HelenOS hangout 2021-08-12 21:30 CEST
=====
Attendees:
   - Jiri Svoboda
   - Marek Benc (DusXMT)

Scribe: Jiri Svoboda

Round table
---
Jiri Svoboda
   - Finished text entry scrolling
   - Fix bug with asprintf() not correctly printing empty string
   - addr48_t restoration (takeaway: document your design decisions in
code!)
   - Added Contributing section to README with link to Wiki and guide new
contributors to discuss their ideas on ML
  (also added the same to the Wiki)
   - fix header guards libdevice/libinet
   - created enhancement requests for file manager and new shell
   - Pull requests:
 - deprecate atomic_t / ghostmanbsd - merged
 - Configure NS16550 transmission format settings / DusXMT - merged
 - performance boost on raspberry pi / maurizio-lombardi - merged
 - head, grep - closed with explanation

Marek Benc (DusXMT)
   - Configure NS16550 transmission format settings (first contribution)
   - Would like to write HelenOS driver for Intel 810 integrated graphics
(note: introduced 1999) to allow HelenOS to run in graphics mode on his old
PC which lacks VBE support
   - Plan: port Linux Fbdev driver (GPL)
   - JSv: We prefer drivers written from scratch / BSD
   - DusXMT: I could write it, but not integrate
   - JSv: That would be a shame. Perhaps the ported driver could be used as
a stepping stone to writing a brand new driver

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

"
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the HelenOS hangout 2021-08-12

2021-08-16 Thread Jiri Svoboda
HelenOS hangout 2021-08-12 21:30 CEST
=
Attendees:
   - Jiri Svoboda
   - Marek Benc (DusXMT)

Scribe: Jiri Svoboda

Round table
---
Jiri Svoboda
   - Finished text entry scrolling
   - Fix bug with asprintf() not correctly printing empty string
   - addr48_t restoration (takeaway: document your design decisions in
code!)
   - Added Contributing section to README with link to Wiki and guide new
contributors to discuss their ideas on ML
  (also added the same to the Wiki)
   - fix header guards libdevice/libinet
   - created enhancement requests for file manager and new shell
   - Pull requests:
 - deprecate atomic_t / ghostmanbsd - merged
 - Configure NS16550 transmission format settings / DusXMT - merged
 - performance boost on raspberry pi / maurizio-lombardi - merged
 - head, grep - closed with explanation

Marek Benc (DusXMT)
   - Configure NS16550 transmission format settings (first contribution)
   - Would like to write HelenOS driver for Intel 810 integrated graphics
(note: introduced 1999) to allow HelenOS to run in graphics mode on his old
PC which lacks VBE support
   - Plan: port Linux Fbdev driver (GPL)
   - JSv: We prefer drivers written from scratch / BSD
   - DusXMT: I could write it, but not integrate
   - JSv: That would be a shame. Perhaps the ported driver could be used as
a stepping stone to writing a brand new driver
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Hangout starts today at 21:30 CEST

2021-08-12 Thread Jiri Svoboda

Hi,




just a reminder our hangout starts at 21:30. Yesterday I tried to send e-
mail to the participants via Google Calendar, but not sure if it worked. You
should receive reminder from Google 30 minutes ahead of time. If you have 
any trouble connecting, let me know, I am available on IRC.




See you there!

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Interested in joining tomorrow's hangout

2021-08-05 Thread Jiri Svoboda

Hi Marek!




A little correction, the hangout is next week (August 12th), not this week.
Perhaps I was not clear enough. Anyway, I was able to add you as participant
(wasn't sure if I had the right to do this), so you should see the event in
your Google Calendar (if you have one, that is. I'm not sure what would 
happen if you don't have it.) Google should also send notification 30
minutes in advance. If you  have any problems, let me know.




Cheers,

Jiri

-- Původní e-mail --
Od: Marek Benc <203...@vut.cz>
Komu: helenos-devel@lists.modry.cz
Datum: 5. 8. 2021 12:25:11
Předmět: [HelenOS-devel] Interested in joining tomorrow's hangout
" Hey there!

Jirka invited me on IRC to tomorrow's hangout at 21:30, my google account 
email is xbenc...@vutbr.cz(mailto:xbenc...@vutbr.cz) (for google meet).


With kind regards
Marek Benc
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Minutes of the 105th HelenOS project meeting

2021-07-31 Thread Jiri Svoboda
What: HelenOS 105th project meeting
When: July 29, 2021, shortly after 19:00
Who: JJ, JS
Where: Restaurace na Václavce
Scribe: JS

Round table:
JJ:
- secured the ownership of #helenos channel on libera.chat
- updated Wiki information and thus we've formally moved over from freenode.
net
- noticed we have some PRs that may need attention

JS:
- can I get the rights to become #helenos operator?
- chatted with Maurizio on #helenos, invited him to the next hangout
- DOSMBoot
  - DOS program that can load a HelenOS multiboot2-compliant boot image
  - Still WIP, not integrated, available at: https://github.com/jxsvoboda/
dosmboot
  - Can load kernel, but not modules (init binaries, RAM disk), buggy/
unstable
  - When ready, would like to add to HelenOS ISO image alongside GRUB (loads
the same image)
  - Allows easily booting in DOSBox or on an old PC that has CD-ROM but
cannot boot from it
- UI Text entry
  - Entering text, seeking, selecting, copy and paste
  - Still working on: scrolling long text

Legend:
  JJ Jakub Jermář
  JS Jiří Svoboda
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Interview with Martin Děcký on lupa.cz

2021-07-31 Thread Jiri Svoboda

Hi,




thanks to Maurizio for pointing out to me this interview with Martin on 
server lupa.cz:

https://www.lupa.cz/clanky/martin-decky-huawei-vyvijime-ultimatni-nahradu-
androidu/





It's in Czech, here's automatic translation into English:


https://translate.google.com/translate?hl=&sl=cs&tl=en&u=https%3A%2F%2Fwww.
lupa.cz%2Fclanky%2Fmartin-decky-huawei-vyvijime-ultimatni-nahradu-androidu%2
F




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Our IRC channel has moved to libera.chat

2021-07-23 Thread Jiri Svoboda

Great, thanks Jakub!




Cheers,

Jiri

-- Původní e-mail --
Od: Jakub Jermář 
Komu: helenos-devel@lists.modry.cz
Datum: 22. 7. 2021 19:56:49
Předmět: [HelenOS-devel] Our IRC channel has moved to libera.chat
"I was able (after a thorough authentication procedure) to gain ownership 
of the #helenos channel on libera.chat. I also updated the IRC-related
info on our wiki. The only thing left to do is to change the IRC bot to 
start visiting libera.chat instead of the old one. Will PM Martin about 
this.

Jakub

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] 105th HelenOS project meeting

2021-07-20 Thread Jiri Svoboda

Hi everyone!




I am very pleased to announce that the 105th (numbered) HelenOS project 
meeting will take place on Thursday, July 29, 2021 in the evening hours in
Koza Roza restaurant in Beroun, Czech Republic.





We have a unique opportunity to meet face to face while it is possible. It
would be wonderful if you could join us, even if you haven't been very
active lately.





So far the following people confirmed their attendance:
 - Jakub


 - me

 - and our lovely significant others




If you would like to join us, please let me know.




Looking forward to seeing you again




Cheers and best regards,

Jiri


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] We have contact!

2021-07-12 Thread Jiri Svoboda

Anyway, although this is far from complete and the code is quite rough, I 
thought it would be prudent to back up my work to Github and try to document
it while fresh in my head. As a side benefit, you can watch my progress:




https://github.com/jxsvoboda/dosmboot




So this is a DOS application that loads a HelenOS multiboot2 image and runs
it. It allows to boot HelenOS in DOSBox or, in general, a DOS machine that
is unable to boot from CD-ROM.




Regards,

Jiri




-- Původní e-mail --
Od: Jakub Jermář 
Komu: helenos-devel@lists.modry.cz
Datum: 11. 7. 2021 12:40:56
Předmět: Re: [HelenOS-devel] We have contact!
"On 7/11/21 10:04 AM, Jiri Svoboda wrote:
> http://jiri-svoboda.blogspot.com/2021/07/we-have-contact.html

Shouldn't 640K be enough for everyone? :-)

Jakub

>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] We have contact!

2021-07-11 Thread Jiri Svoboda
Absolutely! Absolutely! (https://www.youtube.com/watch?v=IW7Rqwwth84)
-- Původní e-mail --
Od: Jakub Jermář 
Komu: helenos-devel@lists.modry.cz
Datum: 11. 7. 2021 12:40:56
Předmět: Re: [HelenOS-devel] We have contact!
"On 7/11/21 10:04 AM, Jiri Svoboda wrote:
> http://jiri-svoboda.blogspot.com/2021/07/we-have-contact.html

Shouldn't 640K be enough for everyone? :-)

Jakub

>
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel
>


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] We have contact!

2021-07-11 Thread Jiri Svoboda
http://jiri-svoboda.blogspot.com/2021/07/we-have-contact.html

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Travis-ci.org going down

2021-06-15 Thread Jiri Svoboda

Hi Vojta,




it seems to me it's working. Thanks a lot for your quick response!




Cheers,
Jiri

-- Původní e-mail --
Od: Vojtech Horky 
Komu: HelenOS development mailing list 
Datum: 15. 6. 2021 12:04:09
Předmět: Re: [HelenOS-devel] Travis-ci.org going down
"Hi,

I think I managed to finish the migration (it needed a few extra
kicks). I just triggered a rebuild so we will see :-)

Cheers,
- VH

út 15. 6. 2021 v 11:46 odesílatel Jiri Svoboda 
napsal:
>
> Hi,
>
> It seems travis-ci.org is finally shutting down today. I was trying to 
migrate to travis-ci.com a few days ago but didn't quite manage it, I'm not
quite sure what needs to be done. Anybody has an idea if that is a viable 
option?
>
> Regards,
> Jiri
> ___
> HelenOS-devel mailing list
> HelenOS-devel@lists.modry.cz
> http://lists.modry.cz/listinfo/helenos-devel

___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Travis-ci.org going down

2021-06-15 Thread Jiri Svoboda

Hi,




It seems travis-ci.org is finally shutting down today. I was trying to
migrate to travis-ci.com a few days ago but didn't quite manage it, I'm not
quite sure what needs to be done. Anybody has an idea if that is a viable 
option?


Regards,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Taking an early look at HelenOS (version 0.11.1) (3rd party video review)

2021-06-01 Thread Jiri Svoboda
Hi,

I wanted to share with you this video I found on youtube:

Taking an early look at HelenOS (version 0.11.1)
https://www.youtube.com/watch?v=2e4wF75qePw

I liked this. It's very good to look at this kind of video and see what a 
person encountering the system for the very first time is likely to struggle
with.

I'll try to make some quick notes for future reference.

Overall, to an average Joe looking at the OS from a speed train, the system
feels very immature. This may come as a shock to us, but it should not, 
seeing the gaps in the UI (also evidenced by the version number ^_^).

He hates Barber, because it's very distracting/annoying (sorry Martin).
He starts by playing with the terminal, because that's what's presented 
prominently.
He verifies the window can be moved around.
He types 'help' because that what it told him to do.
He notices the OS expects you to be command-line savvy (as it says Bdsh is
the primary interface)
He welcomes line editing/copy/paste, history and mouse-wheel history
scrolling.
He repeats many times "this is a lot of features for a zero-dot-eleven
system that is very early in development."

He tries 'help commands'
He tries to use the virtual consoles, because the survival tips tell him so,
but this does not work, because he's running in desktop mode, not in console
mode(!)
He is surprised that there are virtual consoles.
He is glad there is a user guide online, but does go into it.
'help commands'
He notices 'familiar' and 'unfamiliar' commands
He tries 'kcon' and he does not know how to switch back (tries exit, quit)
and has to reboot

'ls'
'ls app'

He unsuccesfully tries to scroll back the listing, which does not fit the 
screen (!!)

'ping ' - failed

'tetris' (surprised it's text based)
'ls srv'
'devman'
'/srv/devman' - he thinks he is supposed to run things in /srv (afterall the
survival tips suggest this) and realizes it's probably not for the average
user

Starts Calculator from the launcher and is happy with it (controls with 
keyboard and mouse)
Starts UI Demo from launcher (plus points for confusing him with Moire
fractal)
Starts GFX Demo from the launcher (note: not entirely obvious what it's 
doing)

[The end]





I would put some takeaway points:

 - don't underestimate known usability issues like scrollback in terminal
(terminal resizing...) they can be a real problem

 - if you want Joe to try something, you need to put it right under their
nose (e.g. not dead obvious that the system can play sounds)

 - wonder what emulation/virtualization was being used. He seemed to expect
a network connection, but there wasn't one. Why?




Regards,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Hangout this thursday?

2021-05-10 Thread Jiri Svoboda

Hi,




anybody interested in joining the hangout this thursday?




Cheers,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Up-to-date version of meson required

2021-05-05 Thread Jiri Svoboda

Hi,




with commit https://github.com/HelenOS/helenos/commit/923bb331744a3cf
807459524040e34243096fc5f I changed warning_level from 3 to 2. This has an
impact on the version of meson required.




In recent versions of meson (I was not able to find the exact version where
the change happened) the translation of warning levels of 2 and 3 to GCC 
warning options was swapped. In the old days 2 meant -Wpedantic and 3 meant
-Wextra, now (as of version 0.56.2) 2 means -Wextra and 3 means -Wpedantic.




Since HelenOS produces many warnings (and thus errors in debug build) with -
Wpedantic, I changed the level to 2 to fix build with new meson (I hit this
upon upgrading to Fedora 34).




This probably means that, after this change, building with old version of 
meson will produce the same problem. If you encounter this problem after 
pulling in this changeset, you will need to upgrade to newer meson (e.g. 
0.56.2).




Thanks,

Jiri
___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


Re: [HelenOS-devel] Reply to Raspberry Pi query on IRC

2021-03-27 Thread Jiri Svoboda

Forgot to include helenos-devel, which somehow fell out of the loop.


-Jiri



-- Původní e-mail --
Od: Jiri Svoboda 
Komu: GameDevFox 
Datum: 27. 3. 2021 17:42:37
Předmět: Re: Reply to Raspberry Pi query on IRC
"
Hi Ed,




I don't think forcing old version of meson is the best approach, except for
the improbable case that this is actually a bug in meson itself. It rather
looks to me like there is some bug in our build files, or at least some 
construction that has been made obsolete or changed its behavior. We need to
track that down and probably fix our build files.




Cheers,

Jiri

-- Původní e-mail --
Od: GameDevFox 
Komu: Jiri Svoboda 
Datum: 27. 3. 2021 16:42:51
Předmět: Re: Reply to Raspberry Pi query on IRC
"

Hey Jiri,



Thanks for the quick reply.




I found out the reason why my ninja build was failing. It turns out that 
when I ran pip3 install meson it installed version 0.57.1 (the latest) which
would create a ninja build that would fail.




When I uninstalled meson 0.57.1 and reinstalled version 0.50.1 (the version
that gets installed in the .travis.yml build script) and ninja build
succeeds!




I created a pull request that updates the README.md to include this detail
in the pip3 examples. If there are any changes or additions you'd like me to
make to this PR please let me know.

https://github.com/HelenOS/helenos/pull/210
(https://github.com/HelenOS/helenos/pull/210)




Thanks again,


Edward






On Sat, Mar 27, 2021, 5:16 AM Jiri Svoboda mailto:jirik.svob...@seznam.cz)> wrote:

"

Hi GameDevFox,




following up to your query on IRC:

 Hi everyone. Is there anyone willing to help me figure out why
my `arm32/raspberrypi` build is failing when I run `ninja` in my helenos 
build directory?
 A lot of warnings are shown in the logs and the compiler seems
to be treating the warnings as errors, complaining about "ISO C standards"
 If anyone would like to connect, please email me at GameDevFox@
gmail.com(mailto:gamedev...@gmail.com)




Please make sure you are using the correct version of the toolchain built 
via up-to-date version of tools/toolchain.sh (i.e. version from master). The
most likely reason is that you are using a different version of gcc which 
presents different warnings.





[jirka@omelette win31]$ /usr/local/cross/bin/arm-helenos-gcc --version
arm-helenos-gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.





If you have the correct toolchain there should be no warnings. It is
possible to prevent gcc turning warnings to errors, which can be done either
by configuring a non-debug build or removing the lines





if CONFIG_DEBUG
    extra_common_flags += [ '-Werror' ]
endif





from meson/part/compiler_args/meson.build

But I would consider that only as a last-resort solution.




Best regards,

Jiri




"
""___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] Reply to Raspberry Pi query on IRC

2021-03-27 Thread Jiri Svoboda

Hi GameDevFox,




following up to your query on IRC:

 Hi everyone. Is there anyone willing to help me figure out why
my `arm32/raspberrypi` build is failing when I run `ninja` in my helenos 
build directory?
 A lot of warnings are shown in the logs and the compiler seems
to be treating the warnings as errors, complaining about "ISO C standards"
 If anyone would like to connect, please email me at GameDevFox@
gmail.com




Please make sure you are using the correct version of the toolchain built 
via up-to-date version of tools/toolchain.sh (i.e. version from master). The
most likely reason is that you are using a different version of gcc which 
presents different warnings.





[jirka@omelette win31]$ /usr/local/cross/bin/arm-helenos-gcc --version
arm-helenos-gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.





If you have the correct toolchain there should be no warnings. It is
possible to prevent gcc turning warnings to errors, which can be done either
by configuring a non-debug build or removing the lines





if CONFIG_DEBUG
    extra_common_flags += [ '-Werror' ]
endif





from meson/part/compiler_args/meson.build

But I would consider that only as a last-resort solution.




Best regards,

Jiri


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


[HelenOS-devel] HelenOS in the news (zive.cz)

2021-03-23 Thread Jiri Svoboda

https://www.zive.cz/clanky/zahodte-windows-linux-i-macos-uz-roky-mame-ceskou
-helenku-z-matfyzu/sc-3-a-209171/default.aspx




(Thx Jakub)


___
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel


  1   2   3   4   5   >