...bo próbuję skompilować DOS Subsystem for Linux. Na ubuntu w maszynie wirtualnej Oracle VM. (Tak w ogóle to czy to jest DOS w linuxie, czy linux w DOS-ie? Z opisu na tej stronie można by wnioskować, że to drugie - jednakowoż sama nazwa oraz zamieszczony tam obrazek, na którym widnieje napis "SeaBIOS (version ArchLinux ...)", a parę linijek pod nim "Starting MS-DOS", mówią co innego. Tak czy inaczej, potrzebuję DOS-a z możliwością uruchamiania linuxowych programów, a cała historia to grubsza sprawa, wykluta z poszukiwań dosowego playera youtube; takie coś owszem, istnieje (drogą okrężną - posiłkując się szeregiem batchów, wgetem, kilkoma binarkami i zewnętrznym playerem), tyle że wobec nowego jutubowego API v3 jest bezużyteczne; własnym wysiłkiem zdołałem dostosować je w możliwym stopniu do współpracy z obecnym standardem jutuba, niestety wszystko rozbija się o potrzebny na samym końcu link do downloadu video, którego obecnie w prosty sposób, z danych udostępnianych przez jutuba, uzyskać się nie da - i nawet narzędzie takie jak youtube-dl w ostatniej oficjalnej wersji (tj. nie nightly build) w większości przypadków filmiku nie ściągnie).
No i wszystko ładnie-pięknie, ściągnąłem paczkę z githuba, ustawiłem TARGET na i486-linux-musl (choć w opisie podane jest, żeby ustawić i386 - ale to chyba większej różnicy nie robi, skoro mam zamiar uruchomić go na Pentiumie?), wcześniej oczywiście kompilując sobie musl-cross-make. Później przez godzinę próbowałem rozszyfrować, co to znaczy "desired build parallelism". x| No ale to też się udało.
i niestety przy makowaniu doslinux wywala się z poniższym błędem.



i nie wiem, o co chodzi. W sensie - oczywiście według manuala na stronie GNU wszystko jest jasne i klarowne - "brakuje nawiasu zamykającego w referencji do funkcji"... Tylko niech mi ktoś jeszcze pokaże, do której funkcji i gdzie. x| Bo coś takiego jak "drivers/cls/.clk-multiplier.o.cmd" w ogóle nie istnieje (pomijając, że nie mam pojęcia, co ta kropka przed nazwą pliku ma przedstawiać; tj. oczywiście zwykle przedstawia bieżący katalog, ale tutaj nie wiem co robi). W tym katalogu istnieje tylko clk-multiplier.c, o zawartości jak niżej, oraz clk-multiplier.o, które zawiera kod binarny, za to po podglądzie F3 w Midnight Commanderze widać coś takiego jak na rysunku, co również nie rozumiem, skąd się wykluło. x|
wobec powyższego pytanie brzmi: jak pozbyć się błędu.

// SPDX-License-Identifier: GPL-2.0
/*
 * Copyright (C) 2015 Maxime Ripard <maxime.ripard@free-electrons.com>
 */

#include <linux/bitops.h>
#include <linux/clk-provider.h>
#include <linux/err.h>
#include <linux/export.h>
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/of.h>
#include <linux/slab.h>

static inline u32 clk_mult_readl(struct clk_multiplier *mult)
{
	if (mult->flags & CLK_MULTIPLIER_BIG_ENDIAN)
		return ioread32be(mult->reg);

	return readl(mult->reg);
}

static inline void clk_mult_writel(struct clk_multiplier *mult, u32 val)
{
	if (mult->flags & CLK_MULTIPLIER_BIG_ENDIAN)
		iowrite32be(val, mult->reg);
	else
		writel(val, mult->reg);
}

static unsigned long __get_mult(struct clk_multiplier *mult,
				unsigned long rate,
				unsigned long parent_rate)
{
	if (mult->flags & CLK_MULTIPLIER_ROUND_CLOSEST)
		return DIV_ROUND_CLOSEST(rate, parent_rate);

	return rate / parent_rate;
}

static unsigned long clk_multiplier_recalc_rate(struct clk_hw *hw,
						unsigned long parent_rate)
{
	struct clk_multiplier *mult = to_clk_multiplier(hw);
	unsigned long val;

	val = clk_mult_readl(mult) >> mult->shift;
	val &= GENMASK(mult->width - 1, 0);

	if (!val && mult->flags & CLK_MULTIPLIER_ZERO_BYPASS)
		val = 1;

	return parent_rate * val;
}

static bool __is_best_rate(unsigned long rate, unsigned long new,
			   unsigned long best, unsigned long flags)
{
	if (flags & CLK_MULTIPLIER_ROUND_CLOSEST)
		return abs(rate - new) < abs(rate - best);

	return new >= rate && new < best;
}

static unsigned long __bestmult(struct clk_hw *hw, unsigned long rate,
				unsigned long *best_parent_rate,
				u8 width, unsigned long flags)
{
	struct clk_multiplier *mult = to_clk_multiplier(hw);
	unsigned long orig_parent_rate = *best_parent_rate;
	unsigned long parent_rate, current_rate, best_rate = ~0;
	unsigned int i, bestmult = 0;
	unsigned int maxmult = (1 << width) - 1;

	if (!(clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT)) {
		bestmult = rate / orig_parent_rate;

		/* Make sure we don't end up with a 0 multiplier */
		if ((bestmult == 0) &&
		    !(mult->flags & CLK_MULTIPLIER_ZERO_BYPASS))
			bestmult = 1;

		/* Make sure we don't overflow the multiplier */
		if (bestmult > maxmult)
			bestmult = maxmult;

		return bestmult;
	}

	for (i = 1; i < maxmult; i++) {
		if (rate == orig_parent_rate * i) {
			/*
			 * This is the best case for us if we have a
			 * perfect match without changing the parent
			 * rate.
			 */
			*best_parent_rate = orig_parent_rate;
			return i;
		}

		parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw),
						rate / i);
		current_rate = parent_rate * i;

		if (__is_best_rate(rate, current_rate, best_rate, flags)) {
			bestmult = i;
			best_rate = current_rate;
			*best_parent_rate = parent_rate;
		}
	}

	return bestmult;
}

static long clk_multiplier_round_rate(struct clk_hw *hw, unsigned long rate,
				  unsigned long *parent_rate)
{
	struct clk_multiplier *mult = to_clk_multiplier(hw);
	unsigned long factor = __bestmult(hw, rate, parent_rate,
					  mult->width, mult->flags);

	return *parent_rate * factor;
}

static int clk_multiplier_set_rate(struct clk_hw *hw, unsigned long rate,
			       unsigned long parent_rate)
{
	struct clk_multiplier *mult = to_clk_multiplier(hw);
	unsigned long factor = __get_mult(mult, rate, parent_rate);
	unsigned long flags = 0;
	unsigned long val;

	if (mult->lock)
		spin_lock_irqsave(mult->lock, flags);
	else
		__acquire(mult->lock);

	val = clk_mult_readl(mult);
	val &= ~GENMASK(mult->width + mult->shift - 1, mult->shift);
	val |= factor << mult->shift;
	clk_mult_writel(mult, val);

	if (mult->lock)
		spin_unlock_irqrestore(mult->lock, flags);
	else
		__release(mult->lock);

	return 0;
}

const struct clk_ops clk_multiplier_ops = {
	.recalc_rate	= clk_multiplier_recalc_rate,
	.round_rate	= clk_multiplier_round_rate,
	.set_rate	= clk_multiplier_set_rate,
};
EXPORT_SYMBOL_GPL(clk_multiplier_ops);

Ostatnia aktualizacja: 23.01.2024 23:47:33 przez snajper

P.S. tu jeszcze screeny linii 497 scripts/Makefile.build oraz 1757 Makefile:





Ostatnia aktualizacja: 24.01.2024 02:10:48 przez snajper

update
po zmianie targetu kompilatora na i386 efekty są takie, że doslinux w pewnym momencie po wykonaniu J=all script/build-prereq robi zwiechę. A przynajmniej tak mi się wydaje... Podczas testów w Ubuntu na OracleVM za każdym razem najpierw system przestawał reagować na cokolwiek poza ruchem kursora, aż następował reset maszyny. Co dziwne, przed tym resetem cały czas była sygnalizowana aktywność dysku - zarówno odczyt, jak i zapis. Nie pojawiały się natomiast już żadne komunikaty w terminalu i żadnej reakcji na nic.
dziś (wczoraj wieczorem) dałem w końcu sobie spokój z OracleVM i uruchomiłem starszą kostkę Gigabyte Brix, stawiając na niej dla odmiany Pop! OS. I tu efekty takie same - zwis, długo, długo nic (poza migającą diodą dysku), aż reset komputera. Myślałem, że może coś z przygotowanym obrazem dysku DOS-a jest nie tak, więc dla testu zmieniłem mu nazwę. I dalej to samo. Zwiecha następuje w różnych punktach - raz wcześniej, raz później. Zdjęcie podczas jednej takiej zwiechy poniżej.
winę sprzętu raczej wykluczam, skoro testy przebiegały na skrajnie różnych urządzeniach. Jedynym punktem wspólnym może być system, bo Pop! OS to kolejna odmiana Ubuntu...
jak komuś uda się tego doslinuxa z powodzeniem skompilować, to byłoby miło.



Ostatnia aktualizacja: 25.01.2024 02:03:33 przez snajper

jeszcze jeden update.
z tego dobrobytu przez ostatni rok z 32 gigabajtami RAM-u zdążyłem już pozapominać pewne reguły. Stąd przez tyle czasu źródło problemu było dla mnie niezrozumiałe. x| A odkryłem je po kolejnym riserczu w googlach, który naprowadził mnie na komendę dmesg. Z linuxem obcuję raz na ruski rok, to takie podstawy mogą być mi obce.
po prześledzeniu loga odkryłem:

Out of memory: Killed process 211998 (cc1) total-vm:60704kB, anon-rss:2816kB, file-rss:256kB, shmem-rss: 0kB, UID:0, bla bla...
Purging GPU memory, bla.

komputer ma 8 GB, plus 4 GB swap file (wcześniej VM też miała przydzielone 8, a swap nie wiem ile). Zwiększyłem je do 32 (nie wnikając, czy przydzielanie takiego obszaru ma sens przy 8 GB pamięci fizycznej) i zapuściłem "sudo J=all script/build-prereq" jeszcze raz. No i... komputer działa od nocy do tej pory, dysk coś tam mieli, bo dioda się świeci. Dioda ethernetu też raz po raz mryga (choć raczej wysyła pingi, niż by coś intensywnie pobierał). Niemniej już nad ranem obraz przestał być wyświetlany. Nie mam pojęcia dlaczego, bo chyba wszystkie możliwe działania mające na celu oszczędność energii poodptaszałem. Na ruch myszy i klawisze też brak reakcji. No i nie wiem, ile on tak jeszcze zamierza. Ja rozumiem, że w końcu kompilacja całego systemu może trochę zająć, no ale... ten brak obrazu nadal mnie niepokoi.

Ostatnia aktualizacja: 25.01.2024 15:17:11 przez snajper

Rada na przyszłość: w nazwie tematu nie używać zwrotu "na gwałt", bo odstrasza on potencjalnych zainteresowanych.

Ja proponuję zainteresować się programem zram czylli swapem w RAMie.

Szczególnie dobrze działa to przy programach które tak naprawdę deklarują dużo pamięci ale jej całej nie używają np. większe bufory na dane niż są faktycznie używane czy np. trzymanie bajtów w tablicy 32-bit słów itp. lub jeśli zadeklarowana pamięć to tylko tekst. Czyli bardzo duża liczba programów a w tym bardzo pomaga na systemach z małą ilością pamięci z crashowaniem się Chromium.

W nowoczesnym Linuxie przy swapowaniu na dysk też kompresuje się dane bo i tak trzeba poczekać na dysk a zawsze to mniej danych do zapisania na wolnym magazynie. Problemem jest jednak czas dostępu i nawet dysk NVMe ma znacznie mniejszy czas dostępu.

Oczywiście jeśli by na 8GB komputerze połowę dać dla zram to program który używa np. 6GB pamięci będzie działał trochę gorzej ale nie jest to duże spowolnienie a na pewno w przypadku gdy program używa więcej pamięci niż się posiada i potrzeba dumpować pamięć na dysk to gdy zram jest w stanie ją skompresować i uniknąć zapisu na dysk wtedy zysk wydajności jest bardzo duży.

Co do reszty to... MS-DOS... Linux...
Wat? Brzmi to jak jakiś kosmiczny nierealny hack który nie ma prawa działać ale developer o tym nie wiedział i miał za dużo wolnego czasu.
Zapewne w momencie gdy się uruchomi jakiś bardziej skomplikowany program zarówno na DOSie jak i Linuxie to się to wszystko wysypie... ALE kto wie, może jakimś cudem się te dwa OSy nie pogryzą. Ciekawe by to było przetestować na prawdziwym komputerze.

Ja proponuję zainteresować się programem zram czylli swapem w RAMie.

jutro sprawdzę. Po 3 dniach resetuję linuxa i okaże się, co on tam przez ten czas zmalował.
W międzyczasie zapodałem jeszcze raz na VM, dla testu, przydzielając 2x więcej fizycznej pamięci. I to, co on robi, raczej chyba nie jest normalnym objawem, bo zeżarł tę pamięć w tempie ekspresowym.

zram nic nie pomógł. Niemniej udało mi się pójść krok naprzód - okazało się, że ta wersja, do której podlinkowałem, nie jest aktualną. A nowa znajduje się w ogóle gdzie indziej, bo na https://github.com/lpsantil/doslinux
I tutaj już proces wygląda inaczej i przechodzi bez problemu, a na wyjściu dostajesz gotowego zipa do rozpakowania i uruchomienia w dosie. Tyle że - na tym zabawa się kończy, bo chwilę później, po mignięciu komunikatu "Starting DOS Subsystem for Linux, please wait...", następuje restart.


zip z DSL-em jest gotowy do pobrania, więc nawet nie trzeba go samemu budować. Jego też sprawdziłem w pierwszej kolejności - i po niepowodzeniu liczyłem, że może własna kompilacja zadziała. Tu jednak skończyło się podobnie.
jedno, czego nie rozumiem, to na co mu obraz dysku - w sytuacji gdy budując DSL od zera zarówno z umieszczonym w katalogu obrazem, jak i bez, wyjściowy zip jest tej samej wielkości. Być może coś robię źle... tylko nie wiem, co. Albo jednak ten obraz jest już w aktualnej wersji do niczego nie potrzebny, bo w opisie nie wspominają o nim słowem.

sądząc po zawartości Makefile, obraz występuje tam już tylko jako pozostałość po starszej wersji, gdyby ktoś chciał zbudować sobie DSL-a tą drogą.


Ostatnia aktualizacja: 01.02.2024 10:18:17 przez snajper