Как упростить/улучшить Linux?

Нет, ядру то, конечно, проще будет. А пользователю каково?

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

Вобщем, линух можно улучшить, но не таким радикальным способом. Да и улучшение сомнительное.

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

Вроде бы, большинство программ используют вызовы glibc. Просто я предлагаю реализовать то, что возможно, в glibc, а не в ядре. Программам, скорее всего, даже перекомпиляции не потребуется.

>Вобщем, линух можно улучшить, но не таким радикальным способом.

Какие ещё есть предложения?

>Да и улучшение сомнительное.

Может быть. Но, по-моему, скорость работы это если и уменьшит, то не сильно, зато управление памятью будет заметно проще, ведь им будет заниматься ФС.

> Затем в него пишутся аргументы,

ну и где эти данные окажутся? в той самой памяти ядра,
которую вы хотите сэкономить.

> ведь проще - не всегда лучше, но, по-моему, чем
> меньше используется невыгружаемой памяти

будет сложнее, и памяти больше понадобится.

посмотрите fs/exec.c:setup_arg_pages(), bprm->page[]
непосредственно "вставляется" в новую mm процесса
с помощью install_arg_page() без лишнего копирования.

>ну и где эти данные окажутся? в той самой памяти ядра, которую вы хотите сэкономить.

В файловом кэше, который можно при необходимости сбросить на диск.

>посмотрите fs/exec.c:setup_arg_pages(), bprm->page[] непосредственно "вставляется" в новую mm процесса с помощью install_arg_page() без лишнего копирования.

Получается, памяти тратится примерно в два раза меньше... Ну, в общем, я понял, но всё-таки иногда стоит реализовать то, что возможно, не в ядре, а в библиотеках. Кстати, на уровне библиотек можно реализовать метод, требующий меньше памяти, если exec-нутый процесс будет читать аргументы из файла не с помощью read, а с помощью mmap. Тогда лишнего копирования тоже не будет, но, ИМХО, это копирование - сущая мелочь по сравнению с тем, что потом с этими аргументами будет делать glibc.

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

так памяти все равно меньше не будет использоваться! их же
читать придется, и опять таки в память ядра. памяти понадобится
больше. и будет медленнее.

> если exec-нутый процесс будет читать аргументы из файла не с
> помощью read, а с помощью mmap. Тогда лишнего копирования тоже
> не будет,

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

да не в этом дело. не будет это работать. я даже не говорю
о том, что fs может быть read-only, что нужен довольно
дорогой mktemp() и миллион других проблем.

подумайте хотя бы о LD_LIBRARY_PATH. она нужна интерпретеру,
а вы собираетесь копировать envp после exec.

а вообще, попытайтесь сделать. спорю, не получится, зато
узнаете много нового.

ROTFL ;)

Я понял: сделать это можно, причём не очень сложно, но не нужно.

> Я понял: сделать это можно, причём не очень сложно, но не нужно.

нет, вы не поняли :) сделать это трудно, практически невозможно,
и не нужно. впрочем, я могу и ошибаться. тогда покажите код!

> Я понял: сделать это можно, причём не очень сложно, но не нужно.

А ещё можно через сеть - loopback, передавать - тоже очень удобно будет. Какой выигрыш будет от твоих изменений? Как это скажется на скорости и использованию памяти? IMHO, такие "косметические" изменения совершенно не нужны. Для пользы родины лучше другое что-нить покопать :)

>Для пользы родины лучше другое что-нить покопать :)

У кого какие предложения? Может, ФС?

Чето мил человек дурью мается. То, как сделано - нормально. :)

И вообще не стоит лезть в ядро - там и так много людей ковыряется. Вот какую-нибудь очередную виндовую фенечку спортировать на Linux было бы весьма полезно. :)

Вот idle довольно точно сказал, что execve - операция довольно быстрая и для нее такая оптимизация может стать только тормозом.

Надо быстро выделить эту память в ядре и быстро ее отпустить. :)

> У кого какие предложения? Может, ФС?

Интерфейс ядра для написания железячных дров, работающих в user-space, и в случае сбоя внутри драйвера - не валящих систему. И что-бы не намного медленнее работало, чем сейчас есть ;-)

>Интерфейс ядра для написания железячных дров, работающих в user-space, и в случае сбоя внутри драйвера - не валящих систему. И что-бы не намного медленнее работало, чем сейчас есть ;-)

А по-моему, многие беды всех систем (включая linux) от того, что пытаются создать систему, совместимую чуть ли не со всеми предыдущими, поддерживающую чуть ли не все ФС, и т.д. Благо, в *NIX не требуется бинарной совместимости, а требуется только на уровне исходных кодов.

ИМХО, необходима версия linux, поддерживающая, к примеру, хотя бы одну ФС, но чтобы эта ФС была хорошо оптимизирована по скорости и надёжности. Поддерживала бы хотя бы один API, но чтобы он был максимально удобен, и т.д. Можно даже отойти от POSIX. При этом, конечно, никто не мешает выпускать и обычный linux.

> ИМХО, необходима версия linux, поддерживающая, к примеру, хотя бы 
> одну ФС, но чтобы эта ФС была хорошо оптимизирована по скорости и 
> надёжности. Поддерживала бы хотя бы один API, но чтобы он был 
> максимально удобен, и т.д. Можно даже отойти от POSIX. При этом, 
> конечно, никто не мешает выпускать и обычный linux.

Вот FreeBSD и OpenBSD и идут этим путем, только чето не очень получается.

Тем более Вы никогда не спроектируете FS, равно быстро работающую с
огромным количеством мелких файлов и небольшим количеством огромных
файлов.

>>У кого какие предложения? Может, ФС?
Предлогаю добавить для iso9660 параметр монтирования umask

Работая с линуксом с 1998 года я начинаю понимать что он слишком простая система. Может быть можно ее как-нибудь усложнить? Сделать менее удобной? Тогда несомненно в систему потянутся толпы любителей трудностей. Тех, кто получает своеобразное удовольствие от борьбы со сложностями и неудобствами системы.