Константин Шулыпин (Constantine Shulyupin) представил проект по созданию интерактивной карты Linux ядра (http://www.makelinux.net/kernel_map), на которой обозначена структура ядра и связи между входящими в него подсистемами.На карте представлено более 250 базовых структур и функций ядра. При помощи карты, например, можно отследить путь прохождения данных от системного вызова до взаимодействия с оборудованием.
URL: http://lxer.com/module/newswire/view/102659/index.html
Новость: http://www.opennet.me/opennews/art.shtml?num=15756
Здорово, мне пригодится.
как-то... много всего :)
но не букаф... чего-то друго-то...
Мдя... труд огромный, врядли кто-то разберётся без (поллитра, знания ядра, терпения, желания)
:) Вывод: Познать ядро = ( Стать Алкоголиком || Монахом )
>:) Вывод: Познать ядро = ( Стать Алкоголиком || Монахом )*у*вый вывод. И неправильный.
Я бросил пить с лета и ядро для меня стало лишь понятнее.
PS монах не я
Все слышали, Nick не едет на LinuxFest :) (ибо там делать нечего, кроме как бухать)
>Все слышали, Nick не едет на LinuxFest :) (ибо там делать нечего,
>кроме как бухать)можешь себе представить :) Не еду
Странно, по жизни находил кучу более интересных вариантов (LF5, 6, 9 IIRC).
поддерживаю полностью.а по поводу карты, так она маленькая или в ней не всё.
да и плоская она какая-то.
но за труд - ОГРОМНОЕ человеческое спасибо.
Пожалуйста и спасибо!
Разобраться в ядре - это не сложно. Можно и без пол-литры. Не надо отчаиваться :-)
Книжек в электронном виде - море, и на блогах их найти не проблема.
Так что остается только терпение и желание. Я у верен что те кто читают форум обладают и тем и другим.
В идеале (а может и нет), карта ядра должна быть похожа на Google Earth.
Подсистемы - материки, дороги - вызовы.
Всевозможные вызовы из вне (userspace), это все возможные спутники (kdb, IPC, FS, и т.п.)....
Поэт! :)
А что новости молчат...http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.2
Linux 2.6.25.2
commit c493a1dd8b3a93b57208319a77a8238f76dabca2
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Tue May 6 13:58:34 2008 -0400fix SMP ordering hole in fcntl_setlk() (CVE-2008-1669)
commit 0b2bac2f1ea0d33a3621b27ca68b9ae760fca2e9 upstream.
fcntl_setlk()/close() race prevention has a subtle hole - we need to
make sure that if we *do* have an fcntl/close race on SMP box, the
access to descriptor table and inode->i_flock won't get reordered.
As it is, we get STORE inode->i_flock, LOAD descriptor table entry vs.
STORE descriptor table entry, LOAD inode->i_flock with not a single
lock in common on both sides. We do have BKL around the first STORE,
but check in locks_remove_posix() is outside of BKL and for a good
reason - we don't want BKL on common path of close(2).
Solution is to hold ->file_lock around fcheck() in there; that orders
us wrt removal from descriptor table that preceded locks_remove_posix()
on close path and we either come first (in which case eviction will be
handled by the close side) or we'll see the effect of close and do
eviction ourselves. Note that even though it's read-only access,
we do need ->file_lock here - rcu_read_lock() won't be enough to
order the things.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
да тебе же любознательному дают время спокойно загредиццо, не трезвонят дырь.Радуйся и собирай ksplice заплатку.
>> да тебе же любознательному дают время спокойно загредиццо, не трезвонят дырь.Гыгы, афроросиянин.
>>> да тебе же любознательному дают время спокойно загредиццо, не трезвонят дырь.
>
>Гыгы, афроросиянин.+3.14159265
к счастью, это "всего лишь" DoS
>видать, измельченное перо павлина, 2 штуки.измельченное перо пингвина
ждём kernel.google.com - трёхмерная карта ядра линух
я губу уже раскатал, а там за постер бабло платить надо.... но штука полезная наверное возьму, автору спасибо! давно искал нечто подобное
А че, зря чтоли автор горбатился... Жаль только постер на струйнике распечатан...
Постер напечатан на профессиональных фотобумаге и фотопринтере - качество почти полиграфическое.
Чем нарисована эта штука? Не нашёл.Интересуюсь Mind Map разными.
with inkskape
Респект!Очень наглядно показана куча мусора, которую студенты навалили. Именно так и выглядит ламерский код и подход - паутина, награмождение сложных сложностей. Гордится то тут нечем, - вот чего линуксоиды никак не поймут.
250 вызовов ядра? я читал другие источники - более 300. Сам не считал, не до сук. А вот в Plan9 их чуть больше 40 - меньше на ПОРЯДОК. И новых больше не будет независимо от наращиваемого функционала - новый функионал станет файлом. Так же как в 9P новых команд уже добавлять ни к чему. 2<<1 == 4 :) KISS my shiny metal...
Карта замечательная, хорошая работа.
>Очень наглядно показана куча мусора, которую студенты навалили. Именно так и выглядит
>ламерский код и подход - паутина, награмождение сложных сложностей. Гордится то
>тут нечем, - вот чего линуксоиды никак не поймут.
>
>250 вызовов ядра? я читал другие источники - более 300. Сам не
>считал, не до сук. А вот в Plan9 их чуть больше
>40 - меньше на ПОРЯДОК. И новых больше не будет независимо
>от наращиваемого функционала - новый функионал станет файлом. Так же как
>в 9P новых команд уже добавлять ни к чему. 2<<1 ==
>4 :) KISS my shiny metal...Думаю, студенты не наваливают код в линукс уже много лет, с тех пор, как участие в разработке ядра стали принимать такие корпорации, как IBM, RedHat, Novell.
Эффективность систем не стоит сравнивать по количеству системных вызовов, всё зависит от качества реализации и от необходимости тех или иных вызовов; если у нас есть 40 системных вызовов и какое-то действие состоит из 10 системных вызовов и нужно повторять его часто, то намного эффективнее будет ввести соответствующий системный вызов, чтоб один раз переключится в режим ядра и выполнить необходимые действия, нежели 10 раз переходить в режим ядра и обратно. Но всё же в первую очередь зависит от программистов, реализующих соответствующие вызовы; возьмём, например, винду - API-функций несколько тысяч (сколько из них системных - неизвестно), казалось бы любое действие можно было бы выполнить одной функцией, но вот где-то вычитал, что сохранение файла в блокноте приводит чуть ли не к двадцати системным вызовам, так что количество в качество тут не переходит. Введение каждого нового системного вызова продиктовано некоторой необходимостью, я уверен, что адекватность каждого вызова перед внедрением в ядро линукс была проанализирована и необходимость в этих вызовах есть.
"новый функионал станет файлом" - и к чему приведёт обращение к этому файлу? Как минимум к переключению контекста на драйвер, обрабатывающий запросы к этому файлу. Дальше нужно смотреть какой новый функционал предоставляется соответствующим файлом. Если он реализует новый функционал из тех 40 системных вызовов, то далее будет цепочка переходов в режим ядра и обратно (если соответствующий дравер в нём не работает). Собственно чем это отличается от классического системного (ну или библиотечного, в зависимости от ситуации) вызова? Да только интерфейсом...
>KISS my shiny metal......раздался голос из-под плана, ага.
I told all of my friends how they were losers for running UNIX. They
should switch to NT.... That was more or less my constant refrain until
a single pivotal event changed my life: I actually tried to use NT.
-- Philip Greenspun