Jaderné noviny - 10. 10. 2007 (diskuse)

[Jan Kundrát (jkt)]

"embedded realtime řadičové sítě [controller networks]" -- pokud to anglicky bylo "embedded realtime controller network", tak bud "sítě realtimových embedded kontrolerů", nebo "embedded sítě realtimových kontrolerů".

[Jan Kundrát (jkt)]

Aha, tak v originale "embedded, realtime controller networks", takze asi trochu nepresne "realtimové embedded sítě", pripadne "realtimové sítě embedded zařízení", cimz se legantne vyhneme problemu prekladu slova "controller"...

[Hynek (Pichi) Vychodil]

A nebo úplně nejlépe "řídicí embedded sítě" nebo "mebedded řídicí sítě", ale s tím tady asi neprorazím, protože tady neseženu dost zastánců co mají co do činění kybernetikou, průmyslovou automatizací nebo automobilovým průmyslem. Nejlépe někoho, kdo má v oboru doktorát, nebo aspoň diplom inženýra. Nejspíš to ani nebude fráze bůh ví jak vysoko na googlu. Nojo, kultura průměrnosti nám bují a bují.

[Kyosuke]

Tak si napiš na seznam aspoň mě... Teda bez toho doktorátu, ale aspoň s přičichnutím ke kybeře a řídicí technice.

[Prcek]

Par chybicek se vloudilo:

nefungovaly kvůli tomu některé části kódy volající printk().
Konkrétně se Vegard snažit pomoci vývojářům
Tady mozna chybi "by": nový formát by obsahoval pole pro úroveň logování

[Robert Krátký]

Konkrétně se Vegard snažit pomoci vývojářům

Já nerozumět, co vy říkat?

Tady mozna chybi "by": nový formát by obsahoval pole pro úroveň logování

Nechybí. Nový formát (tak, jak ho Vegard navrhoval) obsahoval různé věci. Teď už je neobsahuje, protože patch pozměnil. Ale kdybychom tam to "by" dali, tak by se význam nijak výrazně nezměnil (pokud by to začlenili do jádra, tak _by_...).

Díky za upozornění.

[Jiří J.]

Tak se dívám, že místo informací o Alanovi bych se dočetl, spíše, kde bydlí

Na návrh Alana Coxe přišel Vegard ...

http://www.abclinuxu.cz/kdo-je/alan-cox

[thingie]

Kdyby abc vědělo kde právě je Alan Cox, obsahovalo by proklatě hodnotnou informaci, víc než pár řádků co člověk najde na každém druhém webu, žejo.

[Robert Krátký]

Opraveno.

[Michal Kubeček]

obarvování není užitečné - kdyby bylo, implementovalo by se to už před nějakými 16 lety

Zvláštní způsob uvažování. Zejména když i člověk uvědomí, že stejně by se dalo odpálkovat všechno, co v jádře není od roku 1991…

[Robert Krátký]

Spíš tím asi naráží na to, že je to (z jeho pohledu) tak jednoduchá věc, že už to mohl udělat kdokoliv, kdykoliv a s prstem v nose, kdyby jen chtěl (tj. kdyby to bylo užitečné).

Já bych se spíš trochu bál toho, jak se s tím poperou všechny možné druhy počítačů a zařízení, na kterých Linux běží.

[Michal Kubeček]

Nejlepší by asi bylo udělat to tak, aby klogd nebo syslog-ng uměl v případě potřeby sekvence pro přepínání barev odstranit. Možná by to naopak měl dělat automaticky a naopak jen na vyžádání je tam nechat.

[Lokalizace software je zpatecnictvi a podpora omezencu]

Nevim jak jste spokojeni vy se stavajicim printk(), ale ja jsem spokojen naprosto, navic lokalizace software z mezinarodniho jazyka je zlo, vsichni by se meli naucit anglicky a bez vymlouvani, kazdy ma 2x tydne minimalne 4 hodiny casu k tomuto ucelu pouzitelnemu.

-- Give man a fish and he will eat one day, teach man a fishing and he will eat for a whole life.

[Michal Vyskočil]

Na druhou stranu nějaký kód chyb v jádře také není špatný. Když se ti něco pokazí v Oracle, tak hledáš ORA-XXX a popisek samotný ti může vyletět třeba ve svahilštině (no dobře, některé vypečené popisky podle mě mohou být ve svahilštině ).

[neldor]

Naprosto souhlasim. Podle me by kazda (nebo aspon kazda chybova) zprava kernelu (ale klidne i standardnich GNU utilit, kdyz jsme u toho...) mela mit svuj unikatni identifikator (jako ma Oracle, AIX, TSM a hromada dalsich produktu). Pak se mnohem zjednoussi lokalizace (pro ty, co to potrebuji), dokumentace, a v neposledni rade taky reseni problemu s pomoci Google, protoze jednoznacny identifikator se mnohem lepe vyhledava...

[Michal Kubeček]

Já jsem se ale o lokalizaci vůbec nevyjadřoval (souhlasím s názorem, že lokalizace hlášení jádra není potřeba), mluvil jsem pouze o barvičkách.

[Hoppik]

infrastrukturu

kprint()

nema byt infrastrukturu

printk()

[michich]

Ne. kprint() je právě název toho úplně nového navrženého API. Schválně se jmenuje jinak než tradiční printk().

[Jan Přech]

CAN se vyznačuje spoustou prima vlastností, třeba zajímavou "přirozenou" arbitráží, celkovou robustností na úrovni linkové vrstvy, ale rozhodně ne odolností proti rušení .

Ne, že bych chtěl brečet na špatném hrobě, tohle nedorozumění je samozřejmě už v anglickém originále, píšu to spíš proto, aby to tu někdo nevzal jako fakt, že to tak je. Není. Třeba obyč RS-485 je na tom s odolností proti rušení podstatně líp...

[František Ryšánek]

To by mě zajímalo, proč se snažej naroubovat CAN na sockety, když by úplně stačilo obecné zařízení s pár ioctl plus user-space knihovna. Tak jak to ostatně mnoho let mají někteří dodavatelé PC hardwaru pro CAN, jako třeba německý Peak (aneb Philips SJA-1000 na milion způsobů). Na nejnižší úrovni CAN skutečně nemá tak striktně definované adresy, jako třeba Ethernet nebo IP. Je proto vhodnější mluvit o filtrech na obsah zpráv, kde se poměrně volně rozlišuje hlavička a payload. Jediný smysl, proč bychom mohli chtít, aby na jednom stroji více procesů mohlo čekat na události z CANu na otevřeném "listening" socketu, je to, že si nadefinují různé filtry na obsah CANových zpráv... A zase by tomu líp slušela nějaká obecná knihovna šitá pro potřeby CANu, spíš než přiohnuté sockets API, které je mimochodem už samo o sobě spíš svérázné a "legacy" než elegantní a univerzální

Úplně jiná píseň je CANOpen - nadstavba nad CANem, která specifikuje poměrně složitou hierarchii komunikujících objektů. Cpát to do socketů by byla vysloveně šílenost. Ostatně je to možná i zbytečně složité do jádra. Spíš než v C bych to napsal v C++. Navíc jsem zatím viděl implementované spíš různé podmnožiny, kolikrát nepříliš standardní, než plnohodnotný CANOpen. CANOpen je dost možná složitější a úchylnější než ASN.1 Žádný div, že se nikomu moc nechce, programovat celý ten objektový stack do nějakého MCUčka.

[Jan Přech]

No a teď si zkuste představit, jaká to musela být práce, naprogramovat CANOpen komplet v assembleru tak, jak to udělal jeden maník z české pobočky Rockwellu. Assembler pro mikra mám rád, ale čeho je moc, toho je příliš...

[Petr Tomášek]

Když už máme v jádře CAN, nevíte někdo, zda se pracuje na 1-wire?

[michich]

Myslíš to, co je v Linuxu pod konfigurační volbou Dallas's 1-wire support (CONFIG_W1)?