Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
mozna tak mowic w szarym, zlym i deszczowym swiecie, ale my zyjemy w milej i radosnej rzeczywistosci gdzie to urzytkownik mowi jak program ma dzialac :)
Pozostaje poczekac na autora... mam nadzieje Mono nie pisze programu tylko dla siebie.
drac030: Miałem na myśli wydajność działającego skryptu, a nie usera, który go tworzy. Jeśli przemielenie jednego pliku wymaga zamontowania go, wykonania na nim jakichś operacji, oraz odmontowania, to chyba jasne, że te trzy operacje oddzielnie będą wymagać więcej czasu i ew. mielenia dyskiem, niż gdy zrobi to jeden program za jednym razem - mogąc zmieścić cały atr w cache'u procesora, czyta i zapisuje go raz, nie musząc polegać na tym, jak FUSE i kernel poradzą sobie ze zbuforowaniem tego i owego pomiędzy kolejnymi wywołaniami z przerywającego im shella.
Po co robić "zwykłą" "Kolejną Zabugowaną i Niedokończoną Implementację Obsługi Obrazów I Filesystemów (tm)", jakich wiele, skoro można zrobić taką Pro? :)
epi, masz racje ze lib bylby fajny, ale skoro tak, to wez sobie source od mono - pewnie dostaniesz je bez oporow i napisz.se (a pozniej daj.mi) ale nie wymagaj zaraz wiki i calej tej korporacyjnej otoczki ktora tu swiadomie lub nieswiadomie promujesz
to co jest wymagalo od mono troche pracy i fajnie ze jest chociaz tyle
rozdmuchanie tego w niewiadomo co to juz widzialem gdzie indziej i wiem jak to sie konczy
jesli nie wierzysz, popatrz na tempo prac nad altirra i porownaj do tempa prac nad atari800win+ - aale o co chodzi? no wlasnie, o co?
Autor rzecz jasna zrobi co zechce, ja mam tylko nadzieję, że projekt nie zostanie niniejszym ubity przez "uRZytkowników".
Epi: nie wiem czy zauważasz, ale masz rację tylko przy bardzo wąskim zastosowaniu tego wszystkiego. Do takich wąskich zastosowań jest franny. Może mi przybliż, jak "jeden program za jednym razem ma zmieścić w cache'u procesora" rzeczywisty dysk? Skupiacie się panowie na ATR-ach zupełnie, jakby mona wynalazek miał służyć tylko do ich generowania, podczas gdy dostęp do nich w gruncie rzeczy tylko efekt miły, ale jednakowoż cokolwiek uboczny.
Poza tym podtrzymuję swoje zdanie, "jeden program" co to za jednym razem itd. po prostu będzie niepraktyczny w użyciu, jeśli chodzi nam o normalny dostęp do filesystemu. A mnie właśnie o to chodzi. Więc przeróbka pod tym kątem będzie:
a) zawężeniem istniejących funkcji
b) zbędnym wysiłkiem (którego dokonania jednak nikomu nie bronię, rzecz jasna)
c) powodem do opóźnienia albo całkowitego zaprzestania prac nad tym rowiązaniem.
A było już tak dobrze, ech :P
Ostatnio edytowany przez drac030 (2011-10-24 23:09:45)
Candle: Nad Altirrą ktoś ciągle pracuje, a Atari800win+ chyba został oficjalnie zarzucony, mylę się?
Rzut oka na stronę, którą linkowałem, przekonałby Cię, że podjąłem już pewien wysiłek w tym kierunku. Osobno potraktowany jest interfejs usera (to tylko jeden krótki plik!), osobno różne formaty obrazów dysków, osobno systemy plików. Kod napisany w D uznałem za wystarczająco przenośny (są kompilatory dla Windows, MacOSa, FreeBSD i Linuxa, a skompilowanej biblioteki statycznej można użyć również w innych językach, np. podpiąć pod FUSE).
Co mnie martwi to to, że wielu z nas robi to samo od zera, kończąc z wiecznie niegotowym produktem, zamiast robić wspólnie i być może dojść dalej.
Drac030: Skupiamy się na tym, żeby nie pisać tysięcy programów dla różnych konkretnych zastosowań, w których 90% procent kodu będzie odpowiadać za dokładnie to samo, i będzie zaimplementowane osobno od zera.
Ostatnio edytowany przez epi (2011-10-24 23:20:07)
@xxl: Faktycznie w chwili obecnej zapisanie inicjalizera na dysku jest dość problematyczne. Można to zrobić wykorzystując obraz udostępniony atrfsem w krokach:
1. stat - sprawdzić rozmiar sektora i ich ilość
2. jeśli 256 to pierwsze 3 sektory mają 128b, wpp mają rozmiar jak inne sektory (chyba, że dysk był montowany z -f, wtedy trzeba liczyć)
3. 3 pierwsze sektory zapisać za pomocą dd if=inicjalizer of=image bs=128 count=3
W sytuacji gdy inicjalizer zajmuje więcej miejsca zaczyna się problem, bo trzeba modyfikować vtoc samodzielnie itp. - masa zachodu.
Faktycznie zapis sektorów jest w kodzie trzeba by tylko wystawić go np. jakimś ioctlem (to samo z odczytem sektorów) i napisać mały programik do tego, bo w systemie nie ma możliwości oidp (dd zapisuje bloki danych, ale nie zamarkuje już sektora we VTOC a to by taki programik robił).
Jeśli chodzi o zapis własnego katalogu - jeśli znasz filesystem, to nikt Ci nie zabroni pisać po obrazie (tym udostępnianym przez atrfs) ile dusza zapragnie, ale to można sobie w zasadzie robić nawet na samym ATRze - atrfs daje tu tylko to, że nie musisz analizować nagłówka (potrzebne informacje są dostępne przez stat), no i w następnej wersji będzie automatycznie przy każdym zapisie liczyło crc (jeśli jest użyty).
@epi,fox: Oczywiście nie mam żadnych obiekcji co do stworzenia porządnej biblioteki do manipulacji obrazami i fsami. Ztcw to epi ma już coś porządnie zaczętego - można by to pociągnąć dalej i potem wykorzystać w moich programikach. Też jestem zdania, że należy zacząć od Traca i analizy. Akurat ten fs jest moją przymiarką do FUSE (inaczej do końca życia nie wiedziałbym jak to działa i czy da się w tym coś napisać, jak szybko i czy i jakie są z tym problemy ;]).
Jeśli idzie o "6 instrukcji" to zauważcie, że 2 mounty są potrzebne tylko podczas montowania obrazu który jest w atr. Analoogicznie się ma sprawa z montowaniem dowolnego czegoś co mamy w pliku .img (używa się tylko /dev/loop do tego), ale ilość instrukcji pozostaje niezmienna. Jeśli będziemy mieć support do APT w kernelu i odpowiednie reguły w udev, to podłączając hdd przez usb, lub wkładając cf do kompa montowanie odbywać się będzie jak w przypadku cdromu - automatycznie i bez ingerencji użytkownika.
Faktycznie jest tak, jak mówi Drac030 - cel, jak mi przyświeca to zrobienie mechanizmu systemowego tak, żeby nie pisać kolejnego narzędzia, które w pewnej chwili rozbroi mnie sowimi ograniczeniami. Ponieważ mamy zwykłe obrazy i zwykłe fsy, to robimy systemowy support dla obrazów i fsów. I to wystarczy, a do kopiowania, przeglądania, czy innego psucia niech ktoś sobie używa co tam lubi.
W planach jest narzędzie pomocnicze, które powie jaki (i czy w ogóle) FS jest na zamontowanym (przez atrfs, lub na partycji) obrazie. Oraz drugie, które zależnie od rozpoznanego fsa zamontuje co trzeba jednym poleceniem. Nawiasem mówiąc mount jest dość elastyczny:
$ mount -t fuse#ataridosfs,fuse#spartadosfs image mountpointco spowoduje próbę zamontowania najpierw ataridosfsa a jeśli się to nie uda to spartadosfs. Trzeba by sprawdzić czy mój fs jest pod tym kątem przygotowany, ale na pewno nie jest to jakiś problem w implementacji.
Nie jest to całkiem tak, że sam fs wystarczy, potrzebne są dodatkowe narzędzia:
- mkfs.* do tworzenia filesystemu (czyli odpowiednik funkcji FORMAT dla konkretnego DOSa, a mkatr dla atrfs),
- fsck.* do testowania integralności i czynności naprawczych (taki odpowiednik CLX, VTOCFIX i pewnie jeszcze kilku narzędzi).
Ale nie od razu Kraków zbudowano.
A na koniec powiem, że zapominacie że nie ja pierwszy napisałem coś działającego. Jest plugin Pajero na windowsa, a ja ciągle używam FRANNY autorstwa Bobera, które bardzo mi się przydaje (wielkie dzięki). Poza tym support dla ATR i FSów jest w AspeQt, jest też w SIO2BSD. Może zamiast pisać od nowa coś swojego warto byłoby się lepiej przyjrzeć już istniejącym projektom i zrobić coś na ich bazie/pomóc w rozwoju?
Kod napisany w D uznałem za wystarczająco przenośny (są kompilatory dla Windows, MacOSa, FreeBSD i Linuxa
Dla mnie niewystarczająco (Linux PowerPC), ale zdaję sobie sprawę, że jestem
w mniejszości.
Co mnie martwi to to, że wielu z nas robi to samo od zera, kończąc z wiecznie niegotowym produktem, zamiast robić wspólnie i być może dojść dalej.
Czasem lepiej (i szybciej) zrobić coś od zera niż wczytywać się w kawał
obcego kodu.
Amun-Ra: Z tego pierwszego powodu przerwałem, kiedy pojawiło się Ć, które załatwia nie tylko przenośność między różnymi sprzętami i systemami operacyjnymi, ale też i językami, jeśli trzeba. Z drugiego powodu zaczynałem od zera (choć mogłem rozbebeszać franny). Skoro jest nas tu już co najmniej czterech, którzy mają pomysł/doświadczenie z podejściem do zakodowania tego, to czemu nie zrobić tego razem?
Ostatnio edytowany przez epi (2011-10-24 23:46:31)
$ mount -t fuse#ataridosfs,fuse#spartadosfs image mountpointco spowoduje próbę zamontowania najpierw ataridosfsa a jeśli się to nie uda to spartadosfs.
No i tu ja mam wątpliwość. Co prawda tak się to niby właśnie robi, tzn. mount -t typ_fs /dev/costam, ale czy nie miałoby sensu wbudowanie rozpoznawania systemu plików z automatu?
Ostatecznie taki ataridosfs już ma w sobie trzy różne - acz zbliżone - systemy plików, mianowicie DOS 1.0, DOS 2.x i MyDOS. Czy istnieją przeciwwskazania do tego, żeby automatycznie rozpoznawał każdy format? Tzn. Sparty, DOS-a 3, DOS-a 4, DOS-a XE?
@drac030: Chętniej zrobiłbym pośrednika, który rozpoznawałby format i używał konkretnego specjalizowanego drivera - mógłby to nawet być skrypt shellowy nazwany mount.a8fs i taką nazwę (a8fs) podawałoby się mountowi.
Ataridosfs można też rozbić na osobne fsy, ale naprawdę różnice są tak niewielkie, że wydaje mi się, że szkoda to robić.
A może są jakieś zalety takiego rozwiązania prócz trzymania wszystkiego w jednym miejscu?
Ataridosfs można też rozbić na osobne fsy, ale naprawdę różnice są tak niewielkie, że wydaje mi się, że szkoda to robić.
Tak, bo zasada działania fsów jest taka sama. Podobnie pewnie byłoby z DOS 3 i DOS 4, w których zasada działania jest ta sama, tylko implementacja jest inna. Co nie zmienia faktu, że nie są one kompatybilne, a jednak (tu w przypadku np. ED w wydaniu DOS-a 2.5 i MyDOS-a) user nie musi się tym kłopotać, bo program robi rozpoznanie z automatu. A zatem, skoro już to robi, to chyba konsekwentnie będzie wbudować też automatyczne rozpoznanie i obsługę reszty filesystemów (przede wszystkim SDX).
No tak, ale o ile Atari DOSy 1,2.x,XL,MyDOS nie różnią się wiele, o tyle SpartaDOS ma zupełnie inny FS. A DOS XE jest syntezą obydwu podejść. Ja wydzieliłbym osobno Atari DOSy, Spartę i XE. Co do DOSów 3 i 4 to musiałbym się głębiej przyjrzeć, żeby wyrobić sobie zdanie. Wpakowanie wszystkiego do jednego pliku skończy się osobnymi procedurami na odczyt choćby sektora (z linkiem i bez linku), na odczyt VTOC, mapy sektorów pliku i katalogu, odczyt struktur katalogu itd. Zrobi się zamieszanie. A tak to jest szansa na poprawę czytelności tego kodu co mam i zrobienie z niego ludzi.
No, jak chcesz. Ja bym na Twoim miejscu plwał na estetykę kodu, jeśli miałoby to zaowocować konsekwentnym działaniem programu.
Wpakowanie wszystkiego do jednego pliku skończy się osobnymi procedurami na odczyt choćby sektora (z linkiem i bez linku), na odczyt VTOC, mapy sektorów pliku i katalogu, odczyt struktur katalogu itd. Zrobi się zamieszanie.
Nie trzeba wszystkiego upychać w jednym pliku. Wystarczy, żeby było w jednej binarce. Moim zdaniem lepiej byłoby zrobić program obsługujący obrazy z interfejsem a'la zip/rar niż mount/mkfs/fsck.
Biblioteka to znacznie lepszy pomysł, choćby dlatego że może ściągnąć więcej zainteresowanych - jeden napisze program do edycji atrów pod windę, ktoś postanowi napisać filesystem pod Haiku itp. itd. Będzie więcej oczy patrzących na kod i szybszy rozwój.
Coś na wzór libdsk, jak najbardziej mile widziane. :)
Moim zdaniem lepiej byłoby zrobić program obsługujący obrazy z interfejsem a'la zip/rar niż mount/mkfs/fsck.
Kiedy mamy osobne mount/mkfs/fsck mogą działać mechanizmy systemowe, które wywołują odpowiedni program na odpowiednim rodzaju fsa. Ale jedno drugiego nie wyklucza - można porobić linki symboliczne o odpowiednich nazwach tak, jak to jest w SIO2BSD z mkatr. Chodziło mi raczej o to, że w jednym programie mamy wszystko napakowane, kupę ifów w procedurach na rózne rodzaje fsów, co świadczy o złym projekcie, bo więcej wyjątków niż reguł. Ale może się upieram niepotrzebnie.
Biblioteka to znacznie lepszy pomysł
Biblioteka jak najbardziej, fs służy do czego innego i z biblioteki chętnie skorzysta. Prototyp ma tę zaletę, że nie przywiązuje się do własnych rozwiązań (tak, jak dogłębnie przemyślany i zaprojektowany system).
No, jak chcesz. Ja bym na Twoim miejscu plwał na estetykę kodu, jeśli miałoby to zaowocować konsekwentnym działaniem programu.
:) Hmmmmm. A może by i rzucić to wszystko plwając na estetykę kodu (i pojechać w bieszczady)?
Adamie: ztcp haiku ma obsluge lufs ;)
biblioteka to twor bardziej uniwersalny i niestety wymaga wiecej wysilku.
po prostu trzeba obrac metode sugerowana przez candla i albo te zrodla wziac jedynie jako przyklad, albo po prostu usiasc do porzadnego zaprojektowania (na wspomnianym wiki) api. samo zaimplementowanie to mniejsze wyzwanie, mozna je pozniej krok po kroku robic.
wazniejszy jest sam projekt/szkielet/opisanie interfejsów.
wiki juz jest - pytanie ile osob faktycznie zainteresowanych udzieli sie na nim.
btw. raz jeszcze wychodzi minus zamknietego oprogramowania na przykladzie pluginu pajero... najwyrazniej to kolo musi byc na nowo wynalezione...
Amun-Ra napisał/a:Moim zdaniem lepiej byłoby zrobić program obsługujący obrazy z interfejsem a'la zip/rar niż mount/mkfs/fsck.
Kiedy mamy osobne mount/mkfs/fsck mogą działać mechanizmy systemowe, które wywołują odpowiedni program na odpowiednim rodzaju fsa. Ale jedno drugiego nie wyklucza - można porobić linki symboliczne o odpowiednich nazwach tak, jak to jest w SIO2BSD z mkatr. Chodziło mi raczej o to, że w jednym programie mamy wszystko napakowane, kupę ifów w procedurach na rózne rodzaje fsów, co świadczy o złym projekcie, bo więcej wyjątków niż reguł. Ale może się upieram niepotrzebnie.
Nie do końca. Tworzy interfejs handlerów różnych typów obrazów. Dla każdego z nich dodajesz odpowiedni wpis w takiej tablicy i odpytujesz potem w pętli. Nic nieczytelnego.
mono: gdyby byl sensowny lib, to nawet jak wsio bedzie w jednej binarce finalnie linkowane, mozesz wzgledem nazwy przeciez rozroznic funkcje ktora ma wykonac, tj. mkfs/fsck/extract/costam. jakby nie bylo wiele kodu w tych programach i tak sie duplikuje...
@jellonek: To prawda. Dlatego dawno już napisałem, że biblioteka jest wspaniałą rzeczą i jeśli będzie, to chętnie z niej skorzystam w swoich programach. Wszystkiego naraz nie dam rady zrobić, a gdybym teraz zaczął zespołowo robić bibliotekę, to w czasie odwlekłyby się narzędzia dla moich fsów i jest duża szansa, że (jak mówi draco) projekt nie zostanie ukończony nawet w jakiejś satysfakcjonującej części.
@Amun-Ra: Masz rację. Wg takiego wzorca jest zrobione chociażby testowanie rodzaju tablicy partycji w kernelu.
Edit: Rozwojem biblioteki mogę się zająć po ukończeniu fsów.
Ostatnio edytowany przez mono (2011-10-25 16:49:53)
Zrobiłem patch na kernel linuxowy w wersji 2.6.32, który implementuje support dla partycji KMK/IDEA.
Oto jak się to zachowuje po włożeniu karty CF z 4ma partycjami SDX:
$ tail -F /var/log/syslog
Oct 26 03:49:05 ox kernel: [ 123.766072] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0
Oct 26 03:49:05 ox kernel: [ 123.766088] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xd3fff 0xe0000-0xfffff
Oct 26 03:49:05 ox kernel: [ 123.771870] pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: excluding 0x60000000-0x60ffffff
Oct 26 03:49:05 ox kernel: [ 123.771906] pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa0ffffff
Oct 26 03:49:05 ox kernel: [ 123.771940] pcmcia_socket pcmcia_socket0: cs: memory probe 0xc0000000-0xc7ffffff: excluding 0xc0000000-0xc7ffffff
Oct 26 03:49:05 ox kernel: [ 123.771978] pcmcia_socket pcmcia_socket0: cs: memory probe 0xe4100000-0xe43fffff: excluding 0xe4100000-0xe415ffff
Oct 26 03:49:05 ox kernel: [ 123.783511] pcmcia 0.0: pcmcia: registering new device pcmcia0.0
Oct 26 03:49:05 ox kernel: [ 123.824014] scsi7 : pata_pcmcia
Oct 26 03:49:05 ox kernel: [ 123.824087] ata7: PATA max PIO0 cmd 0x6110 ctl 0x611e irq 18
Oct 26 03:49:06 ox kernel: [ 123.976913] ata7.00: CFA: SanDisk SDCFX-2048, HDX 4.03, max PIO6
Oct 26 03:49:06 ox kernel: [ 123.976922] ata7.00: 4001760 sectors, multi 0: LBA
Oct 26 03:49:06 ox kernel: [ 123.977790] ata7.00: configured for PIO0
Oct 26 03:49:06 ox kernel: [ 123.978056] scsi 7:0:0:0: Direct-Access ATA SanDisk SDCFX-20 HDX PQ: 0 ANSI: 5
Oct 26 03:49:06 ox kernel: [ 123.978444] sd 7:0:0:0: Attached scsi generic sg3 type 0
Oct 26 03:49:06 ox kernel: [ 123.978613] sd 7:0:0:0: [sdb] 4001760 512-byte logical blocks: (2.04 GB/1.90 GiB)
Oct 26 03:49:06 ox kernel: [ 123.978728] sd 7:0:0:0: [sdb] Write Protect is off
Oct 26 03:49:06 ox kernel: [ 123.978735] sd 7:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Oct 26 03:49:06 ox kernel: [ 123.978798] sd 7:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[b]Oct 26 03:49:06 ox kernel: [ 123.979216] sdb:Discovering Atari KMK/IDEA partition table OK
Oct 26 03:49:06 ox kernel: [ 123.992429] Hard disk size is 4001760
Oct 26 03:49:06 ox kernel: [ 123.992438] Partition 0 (pbeg 0, plen 65535, pclsize $80, pindex 0, pstats $80) in slot 1 sdb1 added
Oct 26 03:49:06 ox kernel: [ 123.992450] Partition 1 (pbeg 65535, plen 65535, pclsize $80, pindex 0, pstats $80) in slot 2 sdb2 added
Oct 26 03:49:06 ox kernel: [ 123.992460] Partition 2 (pbeg 131070, plen 65535, pclsize $80, pindex 0, pstats $80) in slot 3 sdb3 added
Oct 26 03:49:06 ox kernel: [ 123.992470] Partition 3 (pbeg 196605, plen 65535, pclsize $80, pindex 0, pstats $80) in slot 4 sdb4 added
Oct 26 03:49:06 ox kernel: [ 123.992480] Partition 4 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 5 passed
Oct 26 03:49:06 ox kernel: [ 123.992488] Partition 5 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 6 passed
Oct 26 03:49:06 ox kernel: [ 123.992496] Partition 6 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 7 passed
Oct 26 03:49:06 ox kernel: [ 123.992503] Partition 7 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 8 passed
Oct 26 03:49:06 ox kernel: [ 123.992511] Partition 8 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 9 passed
Oct 26 03:49:06 ox kernel: [ 123.992518] Partition 9 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 10 passed
Oct 26 03:49:06 ox kernel: [ 123.992526] Partition 10 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 11 passed
Oct 26 03:49:06 ox kernel: [ 123.992534] Partition 11 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 12 passed
Oct 26 03:49:06 ox kernel: [ 123.992542] Partition 12 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 13 passed
Oct 26 03:49:06 ox kernel: [ 123.992550] Partition 13 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 14 passed
Oct 26 03:49:06 ox kernel: [ 123.992558] Partition 14 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 15 passed
Oct 26 03:49:06 ox kernel: [ 123.992565] Partition 15 (pbeg 0, plen 0, pclsize $00, pindex 0, pstats $00) in slot 16 passed[/b]
Oct 26 03:49:06 ox kernel: [ 123.994343] sd 7:0:0:0: [sdb] Attached SCSI removable disk
$ ls -ltra /dev/
razem 1
drwxr-xr-x 2 root root 120 2011-10-26 03:49 bsg
drwxr-xr-x 16 root root 4180 2011-10-26 03:49 .
crw-rw---- 1 root disk 21, 3 2011-10-26 03:49 sg3
drwxr-xr-x 2 root root 3600 2011-10-26 03:49 char
[b]brw-rw---- 1 root disk 8, 20 2011-10-26 03:49 sdb4
brw-rw---- 1 root disk 8, 17 2011-10-26 03:49 sdb1
brw-rw---- 1 root disk 8, 19 2011-10-26 03:49 sdb3
brw-rw---- 1 root disk 8, 18 2011-10-26 03:49 sdb2[/b]
drwxr-xr-x 2 root root 800 2011-10-26 03:49 block
[b]brw-rw---- 1 root disk 8, 16 2011-10-26 03:49 sdb[/b]
drwxr-xr-x 6 root root 140 2011-10-26 03:49 .udev
crw------- 1 root root 5, 1 2011-10-26 03:49 console
crw------- 1 root root 4, 1 2011-10-26 03:49 tty1
crw-rw-rw- 1 root tty 5, 2 2011-10-26 03:50 ptmx
$ xxd -g 1 /dev/sdb1 | head -32
0000000: 00 01 00 04 e0 07 4c 40 04 12 00 ff ff 54 9b 10 ......L@.....T..
0000010: 02 00 d6 3b a3 03 48 44 44 20 20 20 20 20 01 01 ...;..HDD ..
0000020: 21 00 02 fe 00 01 23 34 00 00 00 00 00 00 00 00 !.....#4........
0000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000040: a2 01 a9 00 95 9e 95 96 bd 21 04 95 92 95 9a ca .........!......
0000050: 10 f0 cd 08 03 f0 0b 8d 08 03 a5 93 8d 09 03 20 ...............
0000060: e5 04 a9 00 85 90 18 65 92 85 98 a9 30 85 91 65 .......e....0..e
0000070: 93 85 99 20 f0 04 85 a4 20 f0 04 25 a4 c9 ff d0 ... .... ..%....
0000080: 3a a9 cd 8d e2 02 a9 05 8d e3 02 20 f0 04 85 a0 :.......... ....
0000090: 20 f0 04 85 a1 05 a0 f0 1c 20 f0 04 38 e5 a0 48 ........ ..8..H
00000a0: 08 20 f0 04 28 e5 a1 85 a3 68 85 a2 20 69 05 20 . ..(....h.. i.
00000b0: b8 04 4c 81 04 6c e0 02 6c e2 02 a9 ce a2 05 8d ..L..l..l.......
00000c0: 44 03 8e 45 03 a9 0f 8d 48 03 a9 09 8d 42 03 a2 D..E....H....B..
00000d0: 00 20 56 e4 4c d4 04 8d 04 03 8e 05 03 ad 0a 03 . V.L...........
00000e0: 0d 0b 03 f0 d6 a0 40 8c 03 03 20 59 e4 30 cc 60 ......@... Y.0.`
00000f0: a9 00 85 a3 85 a2 a5 9e 05 9f f0 15 a0 00 b1 9c ................
0000100: 48 e6 9c d0 02 e6 9d a5 9e d0 02 c6 9f c6 9e 68 H..............h
0000110: 60 20 a7 05 a5 9a c5 a2 a5 9b e5 a3 90 1b a5 98 ` ..............
0000120: a6 99 20 d7 04 a2 01 b5 98 95 9c b5 9a 95 9e ca .. .............
0000130: 10 f5 a0 00 b1 9c 4c 00 05 a5 a0 a6 a1 20 d7 04 ......L...... ..
0000140: a5 a0 18 6d 08 03 85 a0 a5 a1 6d 09 03 85 a1 38 ...m......m....8
0000150: a5 a2 ed 08 03 85 a2 a5 a3 ed 09 03 85 a3 4c 11 ..............L.
0000160: 05 a5 a2 d0 02 c6 a3 c6 a2 20 f6 04 a0 00 91 a0 ......... ......
0000170: e6 a0 d0 02 e6 a1 a5 a2 05 a3 d0 e5 60 a2 01 bd ............`...
0000180: 28 04 9d 0a 03 b5 90 95 94 b5 92 95 96 ca 10 ef (...............
0000190: a5 90 a6 91 20 d7 04 a0 01 b1 94 99 28 04 88 10 .... .......(...
00001a0: f8 20 b7 05 20 b7 05 a5 96 05 97 f0 d0 a0 01 b1 . .. ...........
00001b0: 94 99 0a 03 88 10 f8 a5 94 18 69 02 85 94 90 02 ..........i.....
00001c0: e6 95 a5 96 38 e9 02 85 96 b0 02 c6 97 60 45 72 ....8........`Er
00001d0: 72 6f e9 3a 20 6e 6f 20 44 4f 53 9b 00 00 00 00 ro.: no DOS.....
00001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
$ xxd -g 1 /dev/sdb2 | head -32
0000000: 00 01 00 04 e0 07 4c 40 04 12 00 ff ff 7c 00 10 ......L@.....|..
0000010: 02 00 9f ff 14 00 4d 45 44 49 41 20 20 20 01 01 ......MEDIA ..
0000020: 21 00 02 fe 00 01 0a 85 00 00 00 00 00 00 00 00 !...............
0000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000040: a2 01 a9 00 95 9e 95 96 bd 21 04 95 92 95 9a ca .........!......
0000050: 10 f0 cd 08 03 f0 0b 8d 08 03 a5 93 8d 09 03 20 ...............
0000060: e5 04 a9 00 85 90 18 65 92 85 98 a9 30 85 91 65 .......e....0..e
0000070: 93 85 99 20 f0 04 85 a4 20 f0 04 25 a4 c9 ff d0 ... .... ..%....
0000080: 3a a9 cd 8d e2 02 a9 05 8d e3 02 20 f0 04 85 a0 :.......... ....
0000090: 20 f0 04 85 a1 05 a0 f0 1c 20 f0 04 38 e5 a0 48 ........ ..8..H
00000a0: 08 20 f0 04 28 e5 a1 85 a3 68 85 a2 20 69 05 20 . ..(....h.. i.
00000b0: b8 04 4c 81 04 6c e0 02 6c e2 02 a9 ce a2 05 8d ..L..l..l.......
00000c0: 44 03 8e 45 03 a9 0f 8d 48 03 a9 09 8d 42 03 a2 D..E....H....B..
00000d0: 00 20 56 e4 4c d4 04 8d 04 03 8e 05 03 ad 0a 03 . V.L...........
00000e0: 0d 0b 03 f0 d6 a0 40 8c 03 03 20 59 e4 30 cc 60 ......@... Y.0.`
00000f0: a9 00 85 a3 85 a2 a5 9e 05 9f f0 15 a0 00 b1 9c ................
0000100: 48 e6 9c d0 02 e6 9d a5 9e d0 02 c6 9f c6 9e 68 H..............h
0000110: 60 20 a7 05 a5 9a c5 a2 a5 9b e5 a3 90 1b a5 98 ` ..............
0000120: a6 99 20 d7 04 a2 01 b5 98 95 9c b5 9a 95 9e ca .. .............
0000130: 10 f5 a0 00 b1 9c 4c 00 05 a5 a0 a6 a1 20 d7 04 ......L...... ..
0000140: a5 a0 18 6d 08 03 85 a0 a5 a1 6d 09 03 85 a1 38 ...m......m....8
0000150: a5 a2 ed 08 03 85 a2 a5 a3 ed 09 03 85 a3 4c 11 ..............L.
0000160: 05 a5 a2 d0 02 c6 a3 c6 a2 20 f6 04 a0 00 91 a0 ......... ......
0000170: e6 a0 d0 02 e6 a1 a5 a2 05 a3 d0 e5 60 a2 01 bd ............`...
0000180: 28 04 9d 0a 03 b5 90 95 94 b5 92 95 96 ca 10 ef (...............
0000190: a5 90 a6 91 20 d7 04 a0 01 b1 94 99 28 04 88 10 .... .......(...
00001a0: f8 20 b7 05 20 b7 05 a5 96 05 97 f0 d0 a0 01 b1 . .. ...........
00001b0: 94 99 0a 03 88 10 f8 a5 94 18 69 02 85 94 90 02 ..........i.....
00001c0: e6 95 a5 96 38 e9 02 85 96 b0 02 c6 97 60 45 72 ....8........`Er
00001d0: 72 6f 72 3a 20 6e 6f 20 44 4f 53 9b 00 00 00 00 ror: no DOS.....
00001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Partycje są sformatowane z 512-bajtowymi sektorami i widać, że rozpoznawane są 4 istniejące. Nie mam niestety żadnej partycji mydłosowej, żeby sprawdzić jak ataridosfs współpracuje z urządzeniem /dev/sdbN.
Procedura instalacji:
$ apt-get install linux-source-2.6.32
$ su -
# cd /usr/src/
# tar jxf linux-source-2.6.32.tar.bz2
# wget http://mono.i-demo.pl/fuse/linux-source-2.6.32-atari8fs.diff
# patch -p0 linux-source-2.6.32-atari8fs.diff
# cd linux-source-2.6.32
# make menuconfigW tym miejscu należy wejść do menu "File systems->Partition types" i zaznaczyć opcję "Atari XL/XE partition table support".
Po wyjściu i zapisaniu konfiguracji dalej:
# make-kpkg clean
# make-kpkg --initrd --revision=atari8 kernel_image kernel_headers modules_image
# dpkg -i linux-headers-2.6.32.46+drm33.20_atari8_amd64.deb
# dpkg -i linux-image-2.6.32.46+drm33.20_atari8_amd64.deb
# update-initramfs -c -k 2.6.32.46+drm33.20
# update-grubPotem reboot i po starcie można się cieszyć partycjami KMK/IDEA widocznymi pod linuxem.
Suffiks ".46+drm33.20_*_amd64" zależy oczywiście od konkretnej wersji kernela - ponieważ ściągaliśmy go z repozytorium (Ubuntu 10.04 Lucid). Można łatę nałożyć na standardowy kernel i też powinna działać - patch dodaje pliki atari8.* i modyfikuje pliki check.c, Makefile i Kconfig w podkatalogu fs/partition/.
Procedurę instalacji robiłem wg:
- http://uel.jogger.pl/2006/08/05/how-to- … my-kernel/ oraz
- http://peb.pl/linux/854255-kompilacja-k … -04-a.html
bo okazało się, że nie był tworzony plik initrd.img*.
Zapraszam do testowania i zgłaszania życzeń i zażaleń.
Zrobiłem patch na kernel linuxowy w wersji 2.6.32, który implementuje support dla partycji KMK/IDEA.
Oto jak się to zachowuje po włożeniu karty CF z 4ma partycjami SDX:Oct 26 03:49:06 ox kernel: [ 123.978798] sd 7:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [b]Oct 26 03:49:06 ox kernel: [ 123.979216] sdb:Discovering Atari KMK/IDEA partition table OK Oct 26 03:49:06 ox kernel: [ 123.992429] Hard disk size is 4001760 Oct 26 03:49:06 ox kernel: [ 123.992438] Partition 0 (pbeg 0, plen 65535, pclsize $80, pindex 0, pstats $80) in slot 1 sdb1 added
Przed partition # dodałbym nazwęmodułu: żeby wiadomo było co to wyświetla.
$ apt-get install linux-source-2.6.32 ... # make menuconfigW tym miejscu należy wejść do menu "File systems->Partition types" i zaznaczyć opcję "Atari XL/XE partition table support".
Po wyjściu i zapisaniu konfiguracji dalej:
Na Ubuntu powinien być module-assistant, możnaby zrobić paczkę dla niego, żeby nie trzeba było ściągać i rekompilować źródeł. Generacja initrd też by się zrobiła "sama".
generalnie na debianoidach do robienia kernela (automatycznie tworzy i initrd) uzywa sie make-kpkg z paczki kernel-package
to wlasciwie szystko robi za ciebie, jak juz tylko dobrze sie przygotuje patcha na kernel i dorzuci w odpowiednie miejsce
nie pamietam jak sie przygotowuje paczki pod same moduly, tj. jak podnosisz kernel, instalujesz oprocz kernel-image kernel-headers i automatycznie robiona jest paczka z twoim modulem, jak go dobrze przygotujesz pod wspomnianego przez Amun-Ra module-assistant.
Amun-Ra: gpt i msdos part nie daja zadnej informacji o tym jaki modul rozpoznal partycje
mono: atari xl/xe partition table? to na atari 400/800 nie dziala to? :) ztcp APT mialo byc uniwesalnym standardem, a nie tylko pod kmk/idea ;) (side chyba tez uzywa tego rozkladu partycji, myle sie?)
Ostatnio edytowany przez jellonek (2011-10-26 09:43:02)
Mam paczki, które wygenerowałem w opisany wyżej sposób i mogę je udostępnić (amd_64), ale pewnie nie każdy ma taką architekturę. No i ja dla potrzeb SIO2BSD ustawiam sobie jeszcze 1kHz zegar systemowy.
@jellonek: No właśnie kompletnie nie rozumiem dlaczego nie aktualizuje initrd. Niby paczki przygotowałem zgodnie z literą, a tu przy reboot zaskoczenie.
Na Atari 400/800 pewnie działają :) Zmienię na Atari 8-bit. APT (dla SIDE i nowych IDE+) będzie wkrótce obsługiwany.
@Amun-Ra: Dzięki za info o module-assistant. Ja wiem, że najfajniej się instaluje paczkę z managera, ale nie umiem póki co ich przygotować stąd te sążniste opisy instalacji każdego pacza :)
P.S. Paczki (z kmk/idea support + 1khz timer) są wystawione. Instalacja teraz wygląda tak:
$ su -
# cd /usr/src/
# wget linux-headers-2.6.32.46+drm33.20_1khz+atari8_amd64.deb
# wget linux-image-2.6.32.46+drm33.20_1khz+atari8_amd64.deb
# dpkg -i linux-headers-2.6.32.46+drm33.20_1khz+atari8_amd64.deb
# dpkg -i linux-image-2.6.32.46+drm33.20_1khz+atari8_amd64.deb
# update-initramfs -c -k 2.6.32.46+drm33.20
# update-grubStrony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.230 sekund, wykonano 7 zapytań ]