Linux за българи: Форуми

Новак съм в програмирането, затова искам да попитам: може ли с Кдевелоп да се изработва системен софтуер - операционни системи, както и да се управлява самия хардуер на най-ниско ниво? Както и да се изработва графичен интерфейс?
Благодаря

След като си новак не те съветвам да започваш със системно програмиране, за него се иска доста опит и много добро познаване на езика, на който ще пишеш.
KDevelop може би ще може да управлява проекта (изходния код), но за дебъг и тестване няма да успее.
"както и да се управлява самия хардуер на най-ниско ниво" - това го могат само драйвърите    и ОС-а.

И какво разбираш под графичен интерфейс - да използва GTK++ / Qt / XLib или разработка на изцяло нова система?

Можеш да разработваш произволен софтуер. Нищо не те спира да го ползваш за разработка дори и на операционна система, все пак това е само IDE. Ако ползваш gcc и gdb няма да имаш проблеми. Даже в wiki-то на KDevelop има описано как може да се ползва за отдалечено дебъгване с gdb.

За графичният интерфейс би трябвало да нямаш никакви проблеми. Определено там е силата на KDevelop. Все пак повечето програми от KDE са писани с това IDE.

Благодаря за отговорите. Те ме принуждават да задам въпроса си по-общо:
желанието ми е да се науча да програмирам под Линукс и за Линукс. Искам да си избера подходяща среда за програмиране, която да става както за разработване на системен софтуер, така и за приложни програми с графичен интерфейс. Език за програмиране - ц/ц++, освен ако няма по-добър за целта.
Не твърдя, че ще правя нов виндовс или линукс, просто искам да започна с възможно най-добрите средства.
Ще ви бъда задължен.

KDevelop е добра за старт. Определено е най-добрата свободна среда която може да намериш за C и C++. Това ползвам и аз когато програмирам на Linux. Ако ползваш GNOME може да погледнеш и Anjuta, но според мен тя все още не е на нивото на KDevelop. Също може да тестваш Code::BlocksCode::Blocks, това също е много добра среда за разработка, по която обаче постоянно се прави нещо ново и съответно всяка нова версия оправя бъгове, но и носи нови със себе си.

Eclipse + CDT и Netbeans също са доста прилични за С/C++. На мен лично по ми допадат от KDevelop.

Начи питането ти е много общо.

1.За да управляваш хардуера , нормално ти трябват драйвери за ядрото. С новата насока , драйверите да се местят в user пространството , то ще си е писане на програми. Големите
предимства са , че ще може да се използват  библиотеките от дистрото , с което си. Това значи например драйвер , който може да декодира директно MP4 например , или други сложни алгоритми , забранени в ядрото.Големия проблем ще е сигурността , дали няма да пострада от такъв достъп .Надежността на работа обаче , ще се подобри невероятно много.
Та това (ще) е елегантния начин за директен достъп до хардуера днес.

 2.Разбира не е лесно да започнеш от това.А и не е нужно.
Защото драйвери се пишат за нов хардуер, и е малко вероятно , някой преди теб да не е правил нещо , просто интернет е пълен с всевъзможни проекти , почти всичко , каквото си помислиш , някой друг го е помислил преди теб , (е затова харесвам отворения софтуер ).

3. А и е много вероятно , да не ти трябват въобще драйвери , ако става дума например , да управляваш/комуникираш през нвкой порт , като принтерския например.За неща ,които не искат бързодействие или нещо по специално с времената , изобщо не ти трябват драйвери.

И ако трябва да почнеш отнякъде , аз ти препоръчвам да използваш прекрасните qt3 библиотеки и QT3 designer-a,
които са достатъчни , да си свършиш работата.С QT3 designer-a ще си нарисуваш интерфейса , и ще ти направи простичък проект , а ти си пишеш кода , като ще може да миксваш кеф ти "С" , кеф ти "С++" .Мисля , че е ще ти е по лесно.

Благодаря на всички за отзивчивостта! И сега само един - последен въпрос, за да не ставам досаден:
Може ли да се използва вижуал студиото на майкрософт, както и борланд ц++ студиото за същата цел - програмиране за линукс?
Това беше от мен. Оттук нататък ще се поблъскам сам.

Visual Studio може би ще тръгне с wine, а за Борланд няма смисъл на Линукс имаш gcc, който е няколко светлинни години напред  

Амм, не, някои неща могат да се правят в юзърспейс, например файлови системи, защото е възможно и има интерфейс us<->ks, който позволява такива неща.

Но като цяло, не. От една страна е проблем архитектурата - има входно-изходни операции, които не могат да се изпълняват извън ring0, демек кърнълспейс. Друг проблем е paging-a. Значи, много драйвери (например за уебкамери, мрежови карти и т.н), мап-ват паметта на PCI устройството в определен регион от паметта. Лошото е че един потребителски процес не "вижда" паметта линейно, заради пейджинг-а. Тоест, физическият адрес 0х100000 (примерно) може да се мап-не от VM-a и за процеса "bla" да бъде 0х500000. Това става с едни таблици за преобразуване и  е доста сложна работа, трошаща при това и процесорни цикли. Алтернативно, това, което процесът вижда на адрес 0х2000000, реално може да се намира на физически адрес 0х7361263.

Значи да речем, паметта на устройството (нека например това е RX ring buffer на една мрежова карта), по някакъв начин се мап-ва в виртуалната памет, за да може процесът-драйвер да я "вижда". Ами ако случайно този регион влезе в swap-a? Значи тогава за всеки получен пакет ще трябва това да се изчита от диска (например, съзнавам, че е подвеждащ и тъп пример).

Отделно, примерно реализираш (отново) мрежов драйвер. Принципно, когато пристигне някакъв фрейм, хардуер-а вдига един interrupt (IRQ). Обработката на тези прекъсвания става само в кърнълспейс, да речем че там по някакъв начин се направи така, че да се прескача на адрес, мап-нат към някакъв процес. Значи правиш си interrupt handler в userspace. Това е възможно най-лошата идея, поради няколко причини:

1) IRQ handler-a трябва да завърши максимално бързо, защото такива прекъсвания се генерират прекалено често. Значи, ако е в userspace, имаш един "бавен" context switch.
2) Докато се изпълнява това, трябва да се забранят последователни прекъсвания, докато handler-a си свърши работата, иначе ще настанат concurrency проблеми. Това става с sti()/cti(), а те могат да се изпълняват само в ring0.
3) никой няма да ти гарантира, че процесът-драйвер няма да крашне или да бъде убит. При това положение, при вдигане на IRQ-то, процесорът ще джъмп-не на адрес, на който може да има всякакви глупости и машината като цяло да краш-не. Разбира се, има операционни системи, където всички драйвери са в юзърспейс, но там нещата са решени по съвсем различен начин.


И накрая, драйверите и разните подсистеми от ядрото си комуникират. Значи например, драйвера за мрежовата карта изчита един фрейм, правят се там разни фрагментации и т.н, полученият skb отива към netfilter подсистемата, там ако нещо трябва да се нат-ва, дроп-ва и т.н., после ако е част от някакъв сокет отива към тази част от ядрото, която се грижи за state-a на сокета (ако е TCP конекция примерно може да се налага да се пращат потвърждения и т.н.) и чак накрая това нещо се предава към юзърспейс-кото мрежово приложение.

Сега значи имаш мрежов драйвер в юзърспейс и netfilter в кърнълспейс. Понеже както казах, адресното пространство на процеса няма общо с физическата памет, както я вижда ядрото, ще трябва да има голям брой прехвърляния на памет от/до юзърспейс-а чрез copy_to/from_user() - а това троши доста процесорно време.

И като заключение, не мисля, че скоро в линукс масово ще имаме юзърспейс драйвери. А и не вярвам, че има смисъл

muni1, както ivo1204 предложи за графични приложения може да ползваш Qt, но ти препоръчвам версия 4. В нея класовете са доста по-добре подредени и няма толкова много множествено наследяване както в Qt3. Signals/Slots системата е малко бавна (около 10 пъти спрямо стандартните callbacks, но това не се усеща на съвременните компютри).

За това как се пишат драйвъри можеш да започнеш с книгата Linux Device Drivers, а за виртуалната памет с Understanding Linux Virtual Memory Manager.

Значи идеята за „userspace driver“ отдавна се „дъвче“ , обаче спора е
решен:
http://liquidat.wordpress.com/2007....ver-api
http://mail.opensolaris.org/piperma....86.html

И вече има доста драйвери , готови за „userspace“. Например цялата
 I2C структора ще ходи там.Също и „dvb“ (xc5000 е вече там ) :
http://lkml.org/lkml/2007/9/12/328

Това  е един много голям спор , много за/против , ако Linus Torvalds  не бе решил въпроса , щеше да е най големият.Защото става дума за фундаментални неща.Например :
Ама така ще разрешим на фирмите да си правят затворени драйвери ....
Защитата:
Ами сега е по лошо , двоични драйвери , изпълнявани е кернел пространството ... ( ndiswrapper какво прави? ).

Това е голяма и много интересна тема , а също и важна , да...

Доколкото виждам , QT4 е много развит , има страхотни класове , например има клас , ( май имаше подобна задача в конкурса тук ..)
който директно следи промените е дадена директория и ги обработва.
Механизма сигнал/слот е за сигурност първо , и страхотно опростяване на кода , не е  проблем с бързината : механизъм за сигурно извикване на кол-бак функция. Но нищо не те задължава да го ползваш , свобода ...
 Не съм сигурен обаче , дали Дизайнера за  QT4 е  подходяш за начало .

P.P
Начи ето едно малко по подробно описание на механизма  (по  специално за v4l ):
http://www.linuxtv.org/v4lwiki/images/6/6d/General.png
http://www.linuxtv.org/v4lwiki/index.php/V4L2UserspaceLibrary