Új hozzászólás Aktív témák

• #34375 Livius őstag gyuri860213 #34370

  Új Válasz 2024-10-07 15:11:58 #34375

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz gyuri860213 #34370 üzenetére

  How to schedule a task in Windows server
  https://www.youtube.com/watch?v=x7fOlFUnGmw

• #33766 Livius őstag #79484416 #33765

  Új Válasz 2024-01-03 16:36:21 #33766

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz #79484416 #33765 üzenetére

  Már írtam, magában az RNDIS usb0 interface teljesen jól megy, saját fix IP-re állítva bridge nélkül.

  Egyelőre a kernel configból vették ki, tehát nem nagy művelet úrja be patchelni. De azért kíváncsi lennék, akkor mi a helyettesítője innentől kezdve ahhoz, hogy egy Windows 10/11 plug-and-play lásson egy USB ethernetet egy Linux eszközről, ezt elfeljtették leírni. Meg ez most melyik Gadget RNDIS, volt egy legacy meg egy új configfs-es is.
  
  Jah és akkor az Androidon a mobile hot spot internet megosztásnak is vége lesz USB-én keresztül, ezt elfelejtették az elemzésből, hogy ezzel megy.

• #33764 Livius őstag Archttila #33763

  Új Válasz 2024-01-03 13:09:29 #33764

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz Archttila #33763 üzenetére

  Yocto project-vel buildelem a saját disztribúciót. NXP i.MX és AMD-Xilinx Zynq SoC-éra is tudok buildelni, mind a kettőn ugyan úgy nem működteti a bridge a Gadget RNDIS usb0-át, csak a normál eth0-át. Mind a bridge és a Gadget RNDIS is egy alap Linux kernel feature, és a Yocto project az eredeti érintetlen forrásokat használja ezek buildjénél, tehát nincs itt semmi adott OS official fórum ahova ez bevihető, csak az általános igazi haladó Linux-os fórumokon van helye.

• #33762 Livius őstag ubyegon2 #33755

  Új Válasz 2024-01-03 12:20:26 #33762

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz ubyegon2 #33755 üzenetére

  Ha ez tényleg haladó topik akkor várom a választ erre és előzményeire: #33752

  Azért hozzá kell tennem, ha egy motorháztető alatti (kernel közeli) kérdés merül fel itt a "haladó" topikban, nem igen jönnek a válaszok és hozzászólások, ez inkább haladó felhasználók topikja ha jobban megnézzük.

• #33752 Livius őstag bambano #33751

  Új Válasz 2023-12-29 15:56:42 #33752

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz bambano #33751 üzenetére

  A br0 interface-nek van IP cím adva, azon is működik minden DHCP és DNS már csak, a többin nincs semmi beállítás. A bridge jól működteti a LAN-t, ha a desktop PC arra van bedugva egyből jön is a DHCP-től az IP cím és megy a kapcsolat, SSH/SFTP belépéssel tesztelve lett gond nélkül. De a másik USB Gadget RNDIS usb0 interface az nem csinál semmit. Amikor a desktop PC USB-én arra van bedugva akkor unplugged-nek látja, tehát mintha a bridge nem csinálná meg a link kapcsolatot az RNDIS felé, csak az Ethernetes LAN felé van kapcsolata.

• #33750 Livius őstag

  Új Válasz 2023-12-29 12:28:32 #33750

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  Megcsináltam a birdge-et az eth0 és usb0 network adapterre ezen tutorial alapján az brctl-vel.
  How to Configure Network Bridge on Linux?

  Viszont sajnos, a birdgbe rakott adapterekből csak a sima eth0-ás LAN-on működik a hálózat. Az usb0-on nem megy semmi, amikor a desktop PC az USB-és RNDIS-en van összedugva, a Windows 10 úgy látja hogy az RNDIS adapteren a "Network cable unplugged" és így semmi adatforgalom nem megy rajta, amikora a birdge használná ezt az ARM board Linux-ban. Van valakinek ötlete, hogy a Gadget RNDIS-hez a brctl-vel milyen extra beállítás kéne még, hogy úgy menjen jól mint az eth0 is? Sajnos amikor erre a Googée-val rákeresek mindenki más ezt az RNDSI + LAN bridget a desktop PC-én csinálja meg sikeresen, szinte default beállításokkal, de nekem ez most pont ellentétesen kéne az ARM boardon bridgben.

• #33748 Livius őstag f_sanyee #33747

  Új Válasz 2023-12-28 15:37:59 #33748

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz f_sanyee #33747 üzenetére

  Egy sima desktop PC csatlakozik a boardra vagy a gigabit Ethernet LAN-val (direktben bedugva) vagy az USB gadget etherneten. A desktop PC kap IP címet az ARM boardtól, és így egy fix IP-re vagy domain névre elérhető az ARM board, ez jelenleg működik külön-külön. A célom az lenne, hogy ugyan az az IP cím tartomány működjön a LAN-os és az USB ethernetes csatlakozás esetén is. Természetesen a desktop PC úgy van használva, hogy egyszerre csak az egyiken csatlakozik az ARM boardhoz.

• #33745 Livius őstag Lenry #33743

  Új Válasz 2023-12-28 14:55:03 #33745

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz Lenry #33743 üzenetére

  Ok ezen godolkodtam, de milyen utiliy SW-t kéne leszednem hozzá a Linux-hoz vagy milyen kernel beállításokat kell ehhez használni meg interface konfigot?

• #33742 Livius őstag

  Új Válasz 2023-12-28 14:45:49 #33742

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  Sziasztok,

  Egy ARM-es Linux boardon adott egy Gigabit ethernet, USB Gadget ethernet és nyilván saját maga a localhost-val. A dnsmasq-val simán tudok DNS és DHCP servert futtatni egyenként külön PID-en indított dnsmasq service-okkal a külön IP tartományon az igazi Gigabit etherneten és az USB etherneten is.

  Mi lenne a szakmailag tökéletes megoldás Linux-ban arra, hogy az USB ethernetet és a Gigabit ethernetet a Linux OS egy ethernet adapterként összeolvassza, és így akkor csak azon az egyen kéne indítanom a DNS és DHCP servert? Ennek előnye az lenne nekem, hogy mind a két hálózati interface ugyan azt az IP tartományt használná, a board ugyan azon az IP címen lenne elérhető mind a kettő hálózati módban.

• #33448 Livius őstag vicze #33447

  Új Válasz 2023-08-11 09:14:23 #33448

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz vicze #33447 üzenetére

  Ha jól tudom igazából nem is frissíted véglegesen, csak amikor indul a CPU, akkor betöltődik a microkód, tehát másik alaplapon ahol ez nincs, nem úgy indul.

• #33397 Livius őstag bambano #33359

  Új Válasz 2023-07-06 00:08:55 #33397

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz bambano #33359 üzenetére

  Én ahol dolgozom egy saját beágy Linux-os boardhoz a Yocto project-vel buildelek Linux-ot. Ez a Linux a vevőnek elmegy a board-val, tehát komplett FOSS ellenőrzést és dokumentumokat kellett csinálnunk.
  
  Én amit ebből megtanultam, az az, hogy a vevőnek kiszállított SW-ben, ami jelen esetben egy Linux image, minden ami GPL v2 licenses kód, azt ingyenesen a kérésére el kell tudnom küldeni neki, de csak azt, ami ilyen licenses, minden mást megtarthatok magamnak.
  
  Én úgy gondolom, hogy a Red Hat ennél sokkal többet publikált eddig, és most jött el az, hogy már csak és kizárólag a GLP v2-ők lesznek publikálva (ezt majd kérésre ki kell adniuk, de többet semmit). Pl eltudnám azt képzelni, hogy csinálnak egy GitHub oldalt, ahova ezeket amik náluk GPL v2 felrakják, külön külön, de ez után ember legyen a talpán aki, a sok kicsi SW részből egy újabb disztribúciót majd összehackel magának. Talán a Yocto közösség örülne egy linux-rhel reponak, amiből az elszántak ARM és x86-ra egyedi disztribúciókat tudnának összebuildelni maguknak. Ha kb ilyen lesz a Rad Hat jövője, hogy le minimalizálja a publikus tartalmakat, és csak az lesz elérhető ami GPL v2 akkor semmiben nem lehet velük vitatkozni, ez van és kész, ezt megtehetik, igazából én is ezt tenném egy saját cégemben.

• #31329 Livius őstag bambano #31327

  Új Válasz 2021-04-25 12:01:28 #31329

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz bambano #31327 üzenetére

  Fájlátvitelre a Visual Studio és az ingyenes Visual Code is igazából az rsync-et használja, tehát amikor buildelsz, akkor a PC-én lévő project mappádat az ARM-es Linuxra beszinkonrizálja és kész. Utána lescriptelt módon belép az SSH-án ott a gcc-vel fordít egyet és a gdbserverrel együtt elindítja a debugolandó progidat. Innentől kezdve már nincs SSH, a gdbserver saját protokolja szerint megy a debug, aminél nincs hatékonyabb jelenleg.

  Ebben a módszerben, amit az MS megcsinált szerintem sehol semmi kókányolás nincs, maximálisan követ egy unix filozófiát, és a usernek minimalizálja az extra konfigurálási kényszert, tehát nem kell hozzánemértő módon NFS megosztással bajlódni, ami mindenképp külön telepítgetéseket követel és hozzáértő beállítást, az nem lenne user friendly és nem eladható széleskörben.

• #31326 Livius őstag CPT.Pirk #31311

  Új Válasz 2021-04-25 02:52:46 #31326

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz CPT.Pirk #31311 üzenetére

  Amúgy a jelenlegi "state of the art" az lenne, ha a már meglévő C vagy C++ libjeiteket beraknátok egy igazi C/C++-os Python modulba, tehát egy olyan .so-ba amit a python betud importálni, és abból az ehhez megcsinált osztályokkal egy sima python scriptben tudnátok a top level szintű működést megvalósítani.

  Én kb fél éve ezt megcsináltam, egy ugyan ilyen ARM-es Linux alá, és a világ legkorszerűbben és leggyorsabban fejleszthető cucca lett az eredmény ebből.

  Amúgy az Eclipse valamilyen tcf-agent cuccal tudja ugyan azt a gdbserveres debugolást mint a VS2019 vagy a VS Code.

• #31325 Livius őstag CPT.Pirk #31311

  Új Válasz 2021-04-25 02:34:09 #31325

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  válasz CPT.Pirk #31311 üzenetére

  Ha van lehetőséget a R-Pi-re rakni gcc-t és gdbservert meg ami mind kell ahhoz hogy tudj fordítani az SSH-án keresztül akár a beágyas Linuxon, akkor én azt javaslom próbálkozz inkább a Visual Studio 2019-ben lévő remote debug-val. Annak a gdbserver-es verziója a jelenlegi legjobb szerintem.

  Röviden tömören, amikor buildelsz az SSH-án keresztül feltölti a forrásfájlokat, és az R-Pi-ben lévő gcc-vel fordít mindent, és ez a legjobb, így nem megy félre semmi. Aztán amikor debugban futtatod, akkor SSH-án a buildet cuccot elindítja úgy, hogy a gdbserver is megy közben a Linuxon, és azon keresztül tudsz a VS 2019-ben a saját PC-den breakpointozni, meg mindent amit akarsz, úgy hogy valójában a progi az ARM-en fut. Abban is okos a VS2019, hogy a remote Linux fordítójának és rendszereiben elérhető headerjeiről is csinál egy cahcelt állapotot, és 100%-osan tud működni az IntelliSense a Linuxban lévő includok alapján.

  Amúgy ez létezik az Eclipsben is, de kb fél évig tarthat a bekonfigolása, meg én is azt vettem észre, hogy alig van normális blog bejegyzés vagy valami tutorial hozzá, ami gond nélkül ugyan ezt összerakná.

• #31044 Livius őstag

  Új Válasz 2020-12-28 23:51:41 #31044

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Livius

  őstag

  Sziasztok!
  Lenne egy Linux C/C++ programozási kérdésem, de lehet nem is annyira a C/C++ nyelv a lényeg benne, Linux kernel v4.x-et használok.

  A kérdés az, hogy amikor C/C++-ban a pthread.h-et használva indítok egy plusz threadet FIFO ütemezésben úgy, hogy előre attribútumban beállítom neki a CPU affinitást minden magra, a futás közben ezt a Linux hogy fogja figyelembe venni és kezelni? A thread amit indítok egy végtelen ciklusban figyelget egy thread-safe queue-t, és amikor van valami új elem azt kiveszi, majd csinál vele egy két műveletet, aztán megint blockolva várja a következőt. Ez a szál teljesen jól működik, kb 3-4%-os CPU használatot eredményez, de számomra nagyon gyanús az, hogy mintha a Linux véletlenszerűen indítaná az egyik magon a sok közül ezt a threadet, és utána örökké, csak azon a magon futtatja, vagyis a blockolás feloldása után mintha sose lenne olyan, hogy a másik magra kerülne át a futtatása, pedig a másik magon több szabad CPU idő lenne láthatóan htop-ban. Tud valaki valami infót vagy valami jó linket, hogy valami nagy könyv/biblia szerint a több magot is használható threadeknek hogy kéne managelődni a Linuxban a CPU magok között?

Új hozzászólás Aktív témák