Замена devfs

С каждым днём этот разброд идей и реализаций всё хуже и хуже сказывается на репутации линуха...

Сейчас получается что на линух народ переходит с коммерческих юниксов, а потом логичной будет миграция на мелкомягкие оси... Или на Apple, благо мелкософт владеет частью яблочников... Не к добру всё это...

чето я не понял мессаджа, а нахрена удалять то? чтобы букву 'n' спереди добавить?

нет, что б об этой буквке не думать тем, комо devfs не нужен

а потом грепнуть или гавкнуть исходники для оной буквы ? Все равно не понимаю...

> чето я не понял мессаджа, а нахрена удалять то? чтобы букву 'n' спереди добавить?

Для тех кто в танке цитирую:

"I'm not going to be submitting this. But what it is, is a nice proof-of-concept for people who 'just can't live without a in-kernel devfs' to show that it can be done in less than 300 lines of code ..."

--

"Я не буду отсылать этот патч. Это всего лишь эллегантоное доказательство для тех кто не может жить без devfs в ядре, того, что это может быть сделано все в 300 строк кода ..."

ок, thx!

Это-то понятно, но ведь главный принцип: "Работает", - Не трогай!

Зачем выкидывать?
Он-же не мешал!!! Вот, что непонятно!

ЗЫ:
Сам сижу в udev, но просто _НЕПОНЯТНО_ !

> realloc * (*) (26.06.2005 15:28:37)
пишем комент не прочитав что по ссылке ?

Проснись, разброд идей в реализации Линукса последние 5 лет большой

> но ведь главный принцип: "Работает", - Не трогай!

так ведь старые ядра никто не трогает - они навечно остаются такими какие есть и ты всегда можешь их взять с kernel.org, и работать до на них до старости и не трогать.

> Зачем выкидывать? Он-же не мешал!
В том то и дело что лишнее барахло в ядре мешает, потому как пока Линукс работает kernel девелоперы не сидят пьют чай (работает не трожь) , а развивают ядро дальше. Иногда меняют какие-то внутренние ядреные интерфейсы между частями ядра - надо по всему ядру сделать необходимые изменения. В том числе в этом ненужном барахле. Поэтому убрать то что не нужно - это стратегически правильное решение, тем более что "любой" может добавить себе эту часть обратно.

Каким местом оно мешает? Трудно в конфиге это отключить?
Начинает нервировать то, что девелоперы стали больше заниматься политикой и другой ерундой, вместо программирования.

>Сам сижу в udev, но просто _НЕПОНЯТНО_ !
Попробовал проинсталировать UDEV - сыровато!!!
Во первых - дефолтовский udev.rules недодает 70% устройств!
Во-вторых даже самый насыщенный gentoo/udev.rules
не монтирует /dev/misc/hpet
хотя devfsd монтирует все или почти все (кроме таких
устройсив как /dev/modem которые никак нельзя предсказать заранее)
Если они вырежут devfs из ядра - трахиться придется милионам пользователей линуха и очень даже по настоящему ;)

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

А про конфиг - это да, смешно. Хорошая шутка. :)

Не совсем понял твою мысль. Как при развитии ядра devfs может помешать? Раньше не мешал, а теперь мешает?
Относительно конфигов, тоже не совсем ясно. Если отключить devfs в конфиге, то как правило различными дефайнами код с использованием devfs будет исключен. Что не так? А про кривых разроботчиков уже кричать надоело. ;)

> Не совсем понял твою мысль. Как при развитии ядра devfs может помешать? Раньше не мешал, а теперь мешает?

> Относительно конфигов, тоже не совсем ясно. Если отключить devfs в конфиге, то как правило различными дефайнами код с использованием devfs будет исключен. Что не так? А про кривых разроботчиков уже кричать надоело. ;)

Вы, видимо, никогда не сталкивались с разработкой большого проекта. Из моего опыта работы с системой, порядок меньшей, чем ядро - legacy API's must die, так быстро, как это возможно - иначе код превращается в мешанину условий типа "а если вдруг нас вызвали с deprecated набором параметров, то...". и развивать его дальше - затруднительно весьма становится.

>Не совсем понял твою мысль. Как при развитии ядра devfs может помешать? Раньше не мешал, а теперь мешает?

Раньше его поддержка тоже наверняка требовала ресурсов. Но раз уж он теперь legacy, и есть некоторая замена, тратить время на поддержку смысла мало.

>Относительно конфигов, тоже не совсем ясно. Если отключить devfs в конфиге, то как правило различными дефайнами код с использованием devfs будет исключен. Что не так?

Ну да. А потом вдруг кто-нибудь из пользователей включит и начнет орать, что у него ядро не собирается. Потому что разработчики по быстрому интерфейсы внутри ядра переколбасили, а devfs просто не включали в конфигах :)

> Если они вырежут devfs из ядра - трахиться придется милионам пользователей линуха и очень даже по настоящему ;)

IMHO: Так не надо было 2.6 использовать, если не готов к таким изменениям.

С fc3 сидим. Все он додает.

>Как при развитии ядра devfs может помешать?

Больше строк кода - больше багов. Больше строк кода - больше поддерживать.

udev был создан на замену devfs. За последние полгода хорошо обкатан. Нафига с собой все барахло тащить. Ты же не скучаешь по vm из 2.4.9 сидя на 2.4.2x или 2.6?

>А потом вдруг кто-нибудь из пользователей включит и начнет орать

Пусть доки читает, раз такой продвинутый.

> Вы, видимо, никогда не сталкивались с разработкой большого проекта. Из моего опыта работы с системой, порядок меньшей, чем ядро - legacy API's must die, так быстро, как это возможно - иначе код превращается в мешанину условий типа "а если вдруг нас вызвали с deprecated набором параметров, то...". и развивать его дальше - затруднительно весьма становится.

А Microsoft вон ничего, справляется :) Бедные, тяжко наверное им приходится...

> А Microsoft вон ничего, справляется :)

Че, правда штоль?

Ага. winfs не будет, еще какой-то хрени не будет. Но справляется, да...