ГЛЮКИ???

ай-ай-ай... :))) Видать, захвалили красну девицу

Ооооопс приехали. Теперь оно ваще перестало компилиться.

make[3]: Вход в каталог `/usr/src/linux/drivers/parport'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o ieee1284_ops.o ieee1284_ops.c
ieee1284_ops.c: In function `ecp_forward_to_reverse':
ieee1284_ops.c:365: `IEEE1284_PH_DIR_UNKNOWN' undeclared (first use in this function)
ieee1284_ops.c:365: (Each undeclared identifier is reported only once
ieee1284_ops.c:365: for each function it appears in.)
ieee1284_ops.c: In function `ecp_reverse_to_forward':
ieee1284_ops.c:397: `IEEE1284_PH_DIR_UNKNOWN' undeclared (first use in this function)
make[3]: *** [ieee1284_ops.o] Ошибка 1
make[3]: Выход из каталог `/usr/src/linux/drivers/parport'
make[2]: *** [first_rule] Ошибка 2
make[2]: Выход из каталог `/usr/src/linux/drivers/parport'
make[1]: *** [_subdir_parport] Ошибка 2
make[1]: Выход из каталог `/usr/src/linux/drivers'
make: *** [_dir_drivers] Ошибка 2

Видимо Линус или по пьяни или с большого похмелья эти ядра собирал :(

Да, сломали parport. Наверное Linus его не использует.

нет, это ты по пьяни или с похмелья его компилял... bash-2.05$ uname -a Linux vade 2.4.12 #3 Чтв Окт 11 12:50:09 MSD 2001 i686 unknown

В 2.4.9 сломано и NTFS. И никаких намёков на исправления в changelog's последующих версий...

Ну опять началась любимая феня - ядро выпускать раз в 2-3 дня :0))) стабильность и спокойствие блин мать его за ногу

Ммммм.... да.... что-то как-то все совсем не хорошо. Когда ж наконец-то закончится эта битва гигантов, Linux vs Alan. Сколько ж это продолжаться то будет и ... нафига такая гонка. Сначало как-то казалось что все ок, но вот это уже и не смешно как-то: http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.11-dontuse.tar.gz

По поводу parport - лажанулись ребята.

Открываем linux/include/linux/parport.h и изменяем в строке 255 IEEE1284_PH_ECP_DIR_UNKNOWN на IEEE1284_PH_DIR_UNKNOWN.

Parport исправляется очень просто:

в файле /usr/src/linux/drivers/parport/ieee1284_ops.c все ссылки на "IEEE1284_PH_DIR_UNKNOWN" исправляются на "IEEE1284_PH_ECP_DIR_UNKNOWN" после чего парпорт нормально собирается и работает.

Вот только непонятно когда Линус (или еще ктонить) станет тестировать ядра перед тем как выкладывать их ? Когда разрабатывалась ветка 2.2.х такого бардака небыло :( тогда ее действительно можно было называть "стабильной", а щас такое ощущение что это уже 2.5.0-pre0 а не стабильное ядро Ж((

Даааа. Можно ли назвать теперь ветку 2.4 стабильной?

2 AIS

Из patch-2.4.12.gz:

...
diff -u --recursive --new-file v2.4.11/linux/include/linux/parport.h linux/include/linux/parport.h
--- v2.4.11/linux/include/linux/parport.h Sun Aug 12 13:28:01 2001
+++ linux/include/linux/parport.h Wed Oct 10 23:19:30 2001
@@ -251,7 +251,8 @@
IEEE1284_PH_REV_DATA,
IEEE1284_PH_ECP_SETUP,
IEEE1284_PH_ECP_FWD_TO_REV,
- IEEE1284_PH_ECP_REV_TO_FWD
+ IEEE1284_PH_ECP_REV_TO_FWD,
+ IEEE1284_PH_ECP_DIR_UNKNOWN,
};
struct ieee1284_info {
int mode;
...

Так что на самом деле по фигу

Лююди, вы посмотрите на новый VM (представленный в 2.4.11), за него хвалить надо а не ругать. Своп используется только тогда, когда надо, все летает. Круто!

Разница в vm хорошо заметна на такой операции, как shrink vmware-овского диска.
В 2.4.9 пока идет shrink машина респондит с трудом.
В 2.4.12 - никаких проблем.

а что, человеку уже и выпить нельзя? :-)

Так что, руки кривые все же у Линуса. Обещает открыть 2.5

To: linux-kernel@vger.kernel.org
From: torvalds@transmeta.com (Linus Torvalds)

> - Tim Waugh: parport update

.. which is broken.

Not a good week.

On the other hand, the good news is that I'll open 2.5.x RSN, just
because Alan is so much better at maintaining things ;)


Linus

не сломано... такая же фигня как и вышеописанная - недосмотр. В 2.4.10 - уже досмотрели :)

Народ, а в связи с сабжем подскажите, чем и в каком порядке патчить 2.4.8, который у меня стоит, чтобы получилось 2.4.12? Нужно ли прикладывать на него patch-2.4.11 или нет?

> Нужно ли прикладывать на него patch-2.4.11?
Нужно.

Ничего не имею против Linux, но, как говорил Жванецкий:"Тщательней надо, ребята, тщательней! ". К чему я это - ну не готов еще линукс к серьезной работе. И заменять им Solaris или AIX еще рано. С таким подходом к разработке далеко не уедешь. Надо менять подход, а то получиться второй мастдай.

Ничего не надо менять, Линус вам не коммерческая контора и кормить с ложечки не обещал. Кто пользует адра от Линуса -- следите за списком рассылки, кто хочет заменять AIX -- берите соответственный дистрибутив.

"Даааа. Можно ли назвать теперь ветку 2.4 стабильной?"

Пока нельзя. Как только Линус откроет 2.5.х, то 2.4 стабилизируется. Все "игры" перейдут на 2.5 ветку, а от 2.4 уберут свои шаловливые рученки. ;-)))

Вот казус правильно говорит. Можно подумать в МС билды не делают и негоняют у себя. И все они у них просто идеальные. Их просто не выкладывают и правильно вообщем-то делают ибо дурная голова рукам покоя не дает.

не знаю что кому обещал Линус, но порядка нет в разработке ядра это точно. Посмотрите на CVS во FreeBSD. Ну нет там такого бардака. И не валят "все один куском". Если кому-то нужны обновления VM, они их возьмут. Если кто-то считает что в новй версии поломати NTFS, то сделать откат только fs/ntfs совсем просто. не говору уже о том, что совсем легко следить за разницей в ветках и так далее. Никак я не пойму почему линуксовое ядро до сих пор не в CVS.

2bormotov: Таки я думаю, что сам Линус пользует что-то вроде cvs/BitKeeper. Приводить в пример FBSD можно, но не нужно. У Линуса модель разработки/тестирования совсем иная. Заметь, в 91м году команда FBSD уже имела наработки BSD за основу, у Линуса не было ничего. Сейчас FBSD на год (по словам самих FBSD-folks) отстаёт от Линукса по SMP, имеет более слабую поддержку железа. Т.е. при всех преимуществах FBSD таки отстаёт по темпам развития от Linux, а значит модель Линуса эффективнее, хотя и не лишена недостатков. Да и нет, как ты говоришь, бардака, если б был, проект бы загнулся давным давно, есть нормальный процесс релиза/тестирования/багфиксенья.

...просто все пользователи ядер от Линуса являются участниками этого процесса :)

какая нафиг модель? БАРДАК он и есть бардак.

неужели никто кто защищает СВАЛКУ ЯДЕР на kernel.org не пользовал CVS хотя-бы для проектов с >2 разработчиками?

Я уже как-то в ru.linux приводил цитаты из описания, насколько БЫСТРЕЕ и ЭФЕКТИВНЕЕ пошла разработка Python после того как Python-team захостила проект на sourcefoge. Они довольно четко говорят что они ПОЛУЧИЛИ от настолько открытой разработки.

Что там у себя пользует лично Линус, мне не интеерсно до тех пор, пока я не могу пользоваться всеми теми-же удобствами. Про то, что маинтейнеры соотвевующих кусков ядра этим не могут воспользоваться, я просто не говорю. Или таки могут? Если могут - почему регулярно что-толомают из того что работало? Почему не дать анонимный доступ read-only к репозиторию?

Почему авторы arch/cris пишут в README к своей среде разработки

This product uses Linux 2.4.5, but needs some of the functionality of the, as of today (2001-06-26), not yet released Linux 2.4.6. Therefore a patch has been made to add this functionality.

поясните почему оно "not yet released"? Все что касается архитектурнозависимый кусков - все под (c) .*@axis.com. Что мешает Линусу просто молча коммитить их патчи?

Далее, почему для того, чтоб посмотреть отличия "официального ядра" от ядра Кокса (и еще нескольких веток) нужно фактически все дифить руками? Я знаю что естьлюди которые заливают ядра CVS сами. Но почему-бы не вести просто всю работу сразу в CVS?

Народ, не смешите. Делается ветка в репозитории, ставится тэг, и вперед. Каждый в своей ветке делает то, что ему нравится. ProjectManager (или еще кто-то), собирает из всего этого релиз. Остальные кайфуют имея возможность проследить изменеия от версии к версии, в разных ветках, и так далее и тому подобное. Даже сам ProjectManager имеет больше возможности давать поголове. По делу!

Ну не верю я что это все есть и Линуса, и через это пролезают баги вида "вчера работало, сейчас поломали" и получается фокусы как с 2.4.11 и 2.4.12. IMHO таки что-то в консерватории.

На счет отставания FBSD я ничего не говорил. И зависимость технологии и отставания не прямая. очень важен человеческий фактор, т.е. наличие разработчиков, которые просто напишут то, чего нада написать. Грамотно напишут. Вот и весь секрет "отрыва", даже не имея "codebase"

да, и не придийтесь к CVS. Не нравится именно CVS - есть другие системы. В данном случае это не сущесвено что именно пользуется. Конечный пользователь получает все одним куском.

Кста! ядро пухнет. А скажите, нафига мне таскать к себе исходники всех архитектур? У меня приемущесвенно x86. Вот cris - оно вообще сбоку лежит. Остальное нафига? Опять-же, если ГРАМОТНО разбить ядро на модули, то те, кому не нужно S390/итд они его просто не будут cvsup'ить... В общем, БАРДАК.

2bormotov: Чтобы далеко не ходить, спроси прямо Линуса, а? Эти дискуссии уже были не раз и не два, но я уже всё забыл. Что такое CVS и горы разработчиков/проектов я в курсе, потому и не верю, что у самого Линуса нет подобной системы. Но про сам CVS Линус сказал, что он ему неудобен и будет только мешать, а BitKeeper коммерческий, потому не может быть использован в GPL-проекте.

> Чтобы далеко не ходить, спроси прямо Линуса, а?
Это зачем? Чтобы получить очередной ответ типа "отладчики вредны"
от глубоко погрязшего в своих комплексах человека? Спрашивали
его уже, и не раз...

Ню, кто-нибудь ставил этого гаденыша ?

я ставил. :) после установки 2.4.10 я писал, что 3com карточки перестали определятся и сиcтема подвисает при компиляции ядра на reiserfs, т.е. приспнет на пару секунд, потом нормально и т.д. у меня для тестов HP NetServer 4/66 LC, так что заметно, в отличии от celeron466 например. и первое, что я делаю после установки ядра, это компилирую его под ним :). 2.4.10 я признал нестабильным и откатился на 2.4.9 в 2.4.12 похоже эти баги подчистили, а моя 486 стала шуршать пошустрее (на глаз, без тестов), так шта ...

Alex

> Но про сам CVS Линус сказал, что он ему неудобен и будет
> только мешать,

А, ну да, ну да. Всем помогает, а ему помешает.

> а BitKeeper коммерческий, потому не может
> быть использован в GPL-проекте.

Bitkeeper коммерческий, но может быть использован в
GPL-проекте при условии, что репозиторий публикуется
через Web.

Так что все это отмазки человека, нежелающего менять
своих привычек. Ну, каждый свободен жить как ему удобно,
пока его свобода не начинает ограничивать свободу других.
Именно этот случай.

В целом такой сделал вывод я. Жду появления 2.5, потом перепущу еще 2-3 ядрышка, а затем буду пробовать 2.4. А пока и на 2.2.19 жить можно. Но это все IMHO, а остальные как пожелают...

2rivares: Аналогично... Кстати, на 2.2.х я тоже перешёл лишь в
районе 2.2.13, и, видимо, правильно сделал, что не раньше, судя
по конфам...

2bormotov: Почему бы тебе самому этим не заняться? Глядишь,
полезное дело сделал бы... Если CVS это так круто, то, наверняка,
все сразу переползут... Тот же RedHat в первую очередь...
CVS - это клёво, но его же и админить ещё надо...

вчера "чтил" ядро, вырезка из /usr/src/linux/Documentation/kbuild/bug-list.txt:

- 'make dep' uses multistage dependencies, so the .hdepend file contains 'touch' commands. As a result, building a kernel often touches files in include/linux/*.h. This messes up CVS and other systems which like to rely on file dates.

Интересно, зачем вообще touch'ить файлы??? А CVS использует вовсе и не даты, а содержание.

2allter: потому что я bormotov, а не Torvalds.

RH использует CVS, http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc?cvsroot=glibc этим линком я пользовался кода возникла необзходимость поддрежки timezone в uC-Libc. Я быстро и удобно смог проследить кусочек libc заведующий timezone начиная с того момента откуда форкнулась uC-libc. Попробуйте что-либо (да ту-же мою любимую aic7xxx) проследить из kernel-2.0.x до 2.4.x. Или даже не так - проследить от того момоента, когда драйвер адаптека бписал один человек и для линукса и для freebsd, а потом в линуксовой версии появился новый маинтейнер. интересная задачка, для проверки удачности модели разработки?

Админить CVS разумеется нужно. Вот только скажите, Линус сейчас совсем не занимается администрированием? По сути, кроме всего прочего что он делает, он еще и админит патчи других разработчиков. И судя по тому что новое ядро выходит через два-три дня всед за только что вылезшеим ядром с глюками, он не очень хорошо справляется с этой работой в рамках "текужей модели разработки". Я не могу утверждать что с переходом на CVS сходу наступит счастье. Но то, что если проект живет в CVS, и ProjectManager'у легче давать по голове конкретному разработчику - это точно. И это положительно сказывается на стабильности релизов, и на процессе разработки в целом. Про остальные плюсы, поищите таки статью о ом, как python-team перенес проект на SourceForge. Очень инетерсно и доходчиво написано. Я так не смогу рассказать.

В общем, я устал уже повторять, что разработка ядра далека не то что от совершенсва, даже о того, что реально можно сделать не прилагия особых усилий. Единсвенная реальная проблема - упрямство Линуса Торвальдса. В свете этого мне совсем кажутся смешными его слова, что он думает о том, как сделать линукс лучше... По крайней мере, я не понимаю как можно думать о станах и крыше, совсем не думая о финдаменте.

Грустно. Очень грустно.

2anonymous (*) (2001-10-12 09:53:44.0): не совсем. Он не ограничивает ничью свободу. Он просто не стремится привлекать новых разработчиков. не стремится к тому, чтоб ошибки было проще искать. Наверное ему просто не нужно это. Ну и ладно - его право.

А как Вам такая подача.
Конфигурация все ок, без каких-либо наворотов. make bzImage выдает следующее:

gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o loopback.o loopback.c
In file included from loopback.c:51:
/usr/src/linux-2.4/include/net/sock.h:739: size of array `__pad' is too large
make[3]: *** [loopback.o] Ошибка 1

Лезем в тот самый sock.h и там наблюдаем следующее:
u8 __pad[SMP_CACHE_BYTES - sizeof(int)];

я конечно не сильный профи в разработке ядра, но я прекрасно понимаю, что переменная SMP_CACHE_BYTES, явно не подменилась, во время автоконфига. Вопрос куда рыть в таком случае? Поиск по всем каталогам (/usr/src/linux) ничего толкового нидал.

куда рытьь

на разогнаных машинах всякие "чудеса" бывают...

Вся беда в том, что машина обсолютно честная, да еще с запасом будет

a kompilyator kakoi 2.96 -3.0x ?

куда рытьь

ну на gcc 3.01 это ты зря гонишь.

2anonymous (*) (2001-10-12 15:59:45.0): А чему равен SMP_CACHE_BYTES?

2anonymous (*) (2001-10-12 15:59:45.0): А у тебя что машина много процессорная? :)
Да кстати, смотри определение CONFIG_X86_L1_CACHE_SHIFT
2chuchelo: Лучше уж по теме чего-то сказанул бы...

куда рытьь

2Ogr читать научись, все мои предыдущие сообщение в этом триде либо по теме новости либо ответы на другие сообщения.

Прива фольки!

Вот я тут прочитал ваши дискуссию о новейших технологиях, что происходит на западе и в Америке - что ровно, а что нет; мона ли использовать ядро из Европы, чем Американское лучше... и т.д. и т.п.

Я тут просто хотел узнать есть ли у нас здесь; в России и в СНГ люди, которые могли бы объединиться в комманду и написать свою собственную операционку - видимо легко с нашими отечественными профами (ведь все же в мире наслышаны про них). Вот мона будет объединиться в комманду и сделать свою ОС, наподобие Линукса или Окон - только получше :)

Ну и конечно же, использовать самые передовые технологии в развитии этого проекта типа CVS и т.п.

Как вы на это смотрите? Только не надо фраз, типа: "Вот пришел студент красноглазый" или "Нашелся умник" - оставьте их при себе - я вполне серъезно.

С уважением,

ведущий разработчик ПО.

2 anonymous (*) (2001-10-13 10:05:05.0):

не нужен никому еще один линукс или еще одна bsd. даже еще одна AtheOS не нужна. Если есть люди, которым инетерсно писать операционки, гораздо эфективнее приссоединиться к уже существующему проекту. Вот олько те кто мог - уже участвуют или в разработке линукса, или bsd, или еще где. Кому что инетерснее.

например лично мне, как разработчику, инетерснее прикладной софт писать. Просто так получилось, что linux на данный момент наиболее удобная платформа для прикладного софта который мы пишем. По совокупности критериев. Как только будет что-то лучшее, он будет выкинут в пользу другого. Производителям желаза выгодно чтоб на их хелезе работало много платформ. Производителям прикладного софта тоже выгодно чтоб их софт работал как можно на большем спектре железа/операционок. Просто не всегда это реально осуществимо. Дорого очень ;)

в противовес, могу скзать что у меня вот знакомые программеры пишут под винды. Потому что для их софта, это лучше. ТОже по совокупности критериев. Критерии другие ;)

> u8 __pad[SMP_CACHE_BYTES - sizeof(int)]; если подумать :)), то SMP_CACHE_BYTES <= 4 отвалит такую ошибку. ни линукса ни gcc под рукой не имею но похоже на старый конфиг после экспериментов с smp... make deepclean после патча и вперед!

PS: ногами не бейте если не то подумал.

На gcc 3.0.1 действительно не нужно гнать. Я на нем живу с самого выхода, и пока никаких нареканий.

Нормально работает :))

"На gcc 3.0.1 действительно не нужно гнать. Я на нем живу с самого выхода, и пока никаких нареканий."
У меня xfree4 не компилилось. Уже исправили?