FreeBSD on Niagara UltraSPARC T1

> Уж извините, но это вообще ужоснах. У меня например монитор не резиновый. Монитор он не только по ширине не резиновый, но и по высоте.

> описание IMO нужно в первую очередь для того, чтобы зафиксировать высокоуровневый поток мыслей разработчика aka что же именно он хотел сделать своим действием. а сам код уже вторичен. В однострочных макросах достаточно редко бывает "высокоуровневый поток мыслей разработчика" :)

>>Вы тут спорите, а рядом стоит фря 4.10 и Инет раздаёт.
>>Свет мигает, она перегружается и дальше раздаёт... ;-)
>
>UPS купи, а то дораздается, что винт крякнется. 

UPS стоит дороже, чем этот комп целиком. Так что не куплю. :-)

> Ну да ладно... Вот мой аргумент: виртуальная память существует уже 50 лет. И до сих пор размер страницы больше 8 (или 16) Кбайт ни в одной широко распространенной архитектуре не используется. Поддерживается - но не используется.

Используется, но только для весьма специфических вещей. Например для линуксовской hugetlbfs.

> А Linux - перенесен и работает. По-моему, это весомый довод в пользу "достаточно высокого" качества его исходного кода.

оценка качества продукта просто по факту, что его кто-то потребляет? мы же не будем оценивать качество кода MS Windows из-за ее широкой распространенности? подобное сравнение будет явно не в пользу Linux и всех BSD вместе взятых с хорошом множетелем..

> А вы не пробовали _сравнить_ код Linux с кодом, например, NetBSD?

вы наверное не поверите, но в том числе это мне приходится делать это буквально каждый божий день. работа такая :-/

> Ну да ладно... Вот мой аргумент: виртуальная память существует уже 50 лет. И до сих пор размер страницы больше 8 (или 16) Кбайт ни в одной широко распространенной архитектуре не используется. Поддерживается - но не используется.

...и это, несомненно, очень весомый повод задавать размер блока с опциями монтирования через PAGE_SIZE. ведь она все равно обычно достаточно больщая? ну да, как правило большая. пара кило как минимум, зуб даю. и наврятли кому придет в голову передавать в mount такие большие опции. ну а кто передал - ССЗБ. ну а то, что собственно с размером аппаратной страницы размер блока с опциями монтирования не имеет ровным счетом ничего общего - да и хрен с ним. глнавное, что цифры то почти совпадают и как-то да работает. равно как и тонны других локальных буферов. ну ипстить! работают же..

> P.S. kalafuda, вы кто по профессии? Я - программист, rtc - тоже наврняка программист, мы вам объясняем программистским языком.

вообще то я химик.

> А вы то ли не понимаете, то ли просто троллите. В последнем случае дискуссию пора сворачивать, в первом - скажите, может, мы сможем более понятно объяснить?

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

> А то ваше мнение о MAX_PATH так смахивает на рассуждения о сферическом коне в вакууме...

именно, ибо от результата этого трола ровным счетом ничего не изменится :)

// wbr

> P.S. kalafuda, вы кто по профессии?

Помнится в дискуссии о novell и драйверах он написал что-то вроде "да и менеджер тоже". ПМСМ это многое обьясняет.

>ну а что до дублирования, то foo_mount() в NetBSD делает примерно то-же,

нет вы не правы, fill_super читает супер блок.

mount для каждой FS причем своя:
копирует из/в userspace
ищет по имени устройства ссулку на структуру описывающую ее,
и еще куча мелочей.

Причем этот код в куче ФС один и тот же.

>> А Linux - перенесен и работает. По-моему, это весомый довод в пользу "достаточно высокого" качества его исходного кода. > оценка качества продукта просто по факту, что его кто-то потребляет?

Кто и что в данном случае потребляет ?

Вы тут много говорили по поводу "платформозависимого кода", а когда вам указали на архитектуры на которых никаких других unix-подобных ОС и в заводе не было, выдали вышеприведенную ересь. Замечательно. Такая вот странная платформозависимость :-E

>да, портянка что надо. правда, AFAIR

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

>> Ну да ладно... Вот мой аргумент: виртуальная память существует уже 50 лет. И до сих пор размер страницы больше 8 (или 16) Кбайт ни в одной широко распространенной архитектуре не используется. Поддерживается - но не используется.

> Используется, но только для весьма специфических вещей. Например для линуксовской hugetlbfs.

Я говорил о VM - paging/page protection. 4МБайт страницы используются в Linux не для этого (а для оптимизации использования процессорного кэша или TLB, IIRC).

>> А Linux - перенесен и работает. По-моему, это весомый довод в пользу "достаточно высокого" качества его исходного кода.

> оценка качества продукта просто по факту, что его кто-то потребляет. мы же не будем оценивать качество кода MS Windows из-за ее широкой распространенности?

А что, исходный код Windows широко распространен? Не знал. А оценивать по тому, на скольких _разнообразных_ платформах ОС работает - неплохая метрика, ИМХО.

>> Ну да ладно... Вот мой аргумент: виртуальная память существует уже 50 лет. И до сих пор размер страницы больше 8 (или 16) Кбайт ни в одной широко распространенной архитектуре не используется. Поддерживается - но не используется.

Здесь я протормозил, сорри. ;( Это был ответ на вашу фразу "как это будет работать для систем с PAGE_SIZE в несколько мегабайт".

>>В последнем случае дискуссию пора сворачивать, в первом - скажите, может, мы сможем более понятно объяснить?

>я, вне всяких сомнений, за последний случай. да и обедать уже давно пора :-/

ОК. "Война войной, а обед - по расписанию". 8)

>> А то ваше мнение о MAX_PATH так смахивает на рассуждения о сферическом коне в вакууме...

>именно, ибо от результата этого трола ровным счетом ничего не изменится :)

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

> большинство кода в kern каталоге по крайней мере является кучей малой.

тогда по каким критериям будем оценивать кучу малу?

мне вот, допустим, кажется, что <linux/fs.h> - это яркий пример той самой кучи. тут вам и inode с операциями и file и super_block и символьное/блочное устройства и тесная связка со всеми файловыми системами из дерева и еще бог знает чего - все в одной пачке.

чем-то по стилю очень напоминает <windows.h> a'la "all included!". слава богу, что AFAIK не существует аналогичного fs.c. хотя может быть когда-то давно так они и было, но вовремя разнесли.

// wbr

>тогда по каким критериям будем оценивать кучу малу?

самый простой критерий - легкость нахождения ошибок и модификация.

В CodingStyle есть простое правило для написания функций:
- должна делать только одно действие
- не превышать пары страниц

Это на порядок повышает "легкость нахождения ошибок и модификация" в том
же
linux/kernel
по сравнению с
sys/kern

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

а в чем собственно проблемы даже в пределах текущего POSIX?

допустим, opendir()/readdir()/closedir() не затронуты, а структура dirent не рекомендует использовать sizeof(d_name), только strlen().

http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html#tag_13_08

--- cut ---
The <dirent.h> header shall define the following type:

...

It shall also define the structure dirent which shall include the following members:

ino_t d_ino File serial number.
char d_name[] Name of entry.

...

The name of an array of char of an unspecified size should not be used as an lvalue. Use of:

sizeof(d_name)

is incorrect; use:

strlen(d_name)

instead.

The array of char d_name is not a fixed size. Implementations may need to declare struct dirent with an array size for d_name of 1, but the actual number of characters provided matches (or only slightly exceeds) the length of the filename.
--- cut ---

// wbr

>все-таки, PATH_MAX - это искуственное органичение, явным образом внесенное самими разработчиками ПО в свою систему. в то время как размер страницы PAGE_SIZE - это одно из свойств конкретной процессорной архитектуры, заданное извне производителем конкретного железа.

>совершенно серьезно. по крайней мере, лично я не вижу никакой действительно серьезной идеологической причины ограничивать название файла или полный путь к файлу каким-то лимитом свыше a'la NAME_MAX или PATH_MAX. естественно за исключением чисто технических трудностей, вызванных изначальной кривизной дизайна системы.

А позвольте заметить, на какое ограничение влияет PATH_MAX?

Создается впечатление, что вы не знаете, что ограничивает эта константа.

Полный путь может быть любой длины, только ограничение на имя файла/директории. И что с того?

Как например будет работать система, если в новой ФС (например подключен новый жесткий диск) есть имя файла длиной 1gb, а памяти только 100Mb?

Так что дизайн новых ОС у вас пока не очень получается...

>klalafuda * (*) (23.05.2006 12:40:59)

> В CodingStyle есть простое правило для написания функций:
> - должна делать только одно действие
> - не превышать пары страниц

базово хорошоее в принципе правило, я за.

> Это на порядок повышает "легкость нахождения ошибок и модификация" в том же linux/kernel по сравнению с sys/kern

..а вот тут я не согласен с конечным выводом, пока не приведены конкретные сравнения A с B.

как пример на вскидку: copy_process(), sys_init_module() & so on - явно нарущают первые два правила.

// wbr

> Как например будет работать система, если в новой ФС (например подключен новый жесткий диск) есть имя файла длиной 1gb, а памяти только 100Mb?

совершенно аналогично системе, в которой данные файла 1Gb и 10Mb RAM - а) свапиться б) -ENOMEM.

// wbr

>> Как например будет работать система, если в новой ФС (например подключен новый жесткий диск) есть имя файла длиной 1gb, а памяти только 100Mb?

>совершенно аналогично системе, в которой данные файла 1Gb и 10Mb RAM - а) свапиться б) -ENOMEM.

Файл целиком в память попасть не может, когда памяти мало, а что делать утилите "ls"? Выводить часть названия? :)

>klalafuda * (*) (23.05.2006 14:11:22)

>> Это на порядок повышает "легкость нахождения ошибок и модификация" в том же linux/kernel по сравнению с sys/kern

>..а вот тут я не согласен с конечным выводом, пока не приведены конкретные сравнения A с B.

>как пример на вскидку: copy_process(), sys_init_module() & so on - явно нарущают первые два правила.

Вторая функция занимает 60 строк, что там непонятного?

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

>klalafuda * (*) (23.05.2006 14:09:15)

>как пример на вскидку: copy_process(), sys_init_module() & so on - явно нарущают первые два правила.
> Вторая функция занимает 60 строк, что там непонятного?

мы играем по нами же заданными правилами? сказано было - "две экрана"..
у меня она в 2.4.24 почему-то занимает аж шесть при высоте экрана 45 строк. сюда же можно в принципе добавить do_adjtimex() или do_generic_file_read().

// wbr

>совершенно аналогично системе, в которой данные файла 1Gb и 10Mb RAM - а) свапиться б) -ENOMEM.

> Файл целиком в память попасть не может, когда памяти мало, а что делать утилите "ls"? Выводить часть названия? :)

п.б?

// wbr

>>как пример на вскидку: copy_process(), sys_init_module() & so on - явно нарущают первые два правила. > Вторая функция занимает 60 строк, что там непонятного?

>мы играем по нами же заданными правилами? сказано было - "две экрана".. у меня она в 2.4.24 почему-то занимает аж шесть при высоте экрана 45 строк. сюда же можно в принципе добавить do_adjtimex() или do_generic_file_read().

Можно было бы раскидать инициализацию в init_parameters_0_20(), init_parameters_21_40(), init_parameters_41_60() и т.п.?

Да, есть большие функции, но на читаемость и понимаемость это не влияет.

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

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

>klalafuda * (*) (23.05.2006 14:28:34)

>>совершенно аналогично системе, в которой данные файла 1Gb и 10Mb RAM - а) свапиться б) -ENOMEM.

>> Файл целиком в память попасть не может, когда памяти мало, а что делать утилите "ls"? Выводить часть названия? :)

>п.б?

:) И как тогда стартует система, если у нее в корне такой файл?

scandir/readdir и т.п. перестанут работать и машина с вашей ОС вообще не загрузится.

>klalafuda * (*) (23.05.2006 14:30:03)

> :) И как тогда стартует система, если у нее в корне такой файл? scandir/readdir и т.п. перестанут работать и машина с вашей ОС вообще не загрузится.

- доктор, когда я делаю вот так [чешет правой пяткой левое ухо] у меня почему-то спина болит.
- а вы пробовали так не делать?

ясен пень, что практически в любой системе можно создать весьма трудноразрешимые ситуации. наверное, можно, и образ ядра забабахать на 2xRAM [если сильно постараться, не знаю как]. может, ну его тогда вообще нафик такое ядро..?

ps: примерно так сделали в свое время в QNX4 - вручную в силу тех. причин или же банальной лени в загрузчике системы ограничили размер загрузочного образа до что-то порядка 512kb. чем естественно создали весьма ощутимые проблемы народу, который по каким-то причинам хотел создать образ несколько больше. матов выло предостаточно.

// wbr

> The array of char d_name is not a fixed size.

То есть предлагается использовать динамическое размещение? И сколько памяти размещать (если имя может быть любой длины) ?

> То есть предлагается использовать динамическое размещение? И сколько памяти размещать (если имя может быть любой длины) ?

выделять столько, сколько оно действительно занимает? если оно занимает 500 символов - значит, так действительно необходимо. скорее всего с возможностью ограничения максимального имени файла со стороны администратора на конкретной точке монтирования.

// wbr

>> :) И как тогда стартует система, если у нее в корне такой файл? scandir/readdir и т.п. перестанут работать и машина с вашей ОС вообще не загрузится.

>- доктор, когда я делаю вот так [чешет правой пяткой левое ухо] у меня почему-то спина болит. >- а вы пробовали так не делать?

>ясен пень, что практически в любой системе можно создать весьма трудноразрешимые ситуации. наверное, можно, и образ ядра забабахать на 2xRAM [если сильно постараться, не знаю как]. может, ну его тогда вообще нафик такое ядро..?

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

>klalafuda * (*) (23.05.2006 14:47:28)

>> То есть предлагается использовать динамическое размещение? И сколько памяти размещать (если имя может быть любой длины) ?

> выделять столько, сколько оно действительно занимает?

То есть - какие-то ограничения всё же накладываются? 500 символов - это разумно. Только вот PATH_MAX == 4096. Ну и за что боремся?

> То есть - какие-то ограничения всё же накладываются?

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

> 500 символов - это разумно. Только вот PATH_MAX == 4096. Ну и за что боремся?

за NAME_MAX?

// wbr

> То есть - какие-то ограничения всё же накладываются? 500 символов - это разумно. Только вот PATH_MAX == 4096. Ну и за что боремся?

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

// wbr

> скорее, как возможность и не на уровне сборки системы а отдавая это на откуп пользователю. если ему требуется установить NAME_MAX в 10k - и бога ради. он умный, он знает, что делает.

Каков практический смысл этого ? Вы знаете много людей которые спят и видят как бы им на своем компа имена файлов по 10К забабахать (желательно различиющиеся начиная с 10го кбайта) ?

> Каков практический смысл этого ? Вы знаете много людей которые спят и видят как бы им на своем компа имена файлов по 10К забабахать (желательно различиющиеся начиная с 10го кбайта) ?

khm.. ну в принципе да, видел пару-тройку кому ограничение в 255 символов было явно маловато :)) нет, немного.

// wbr

> Бздуны, а хули во фре до сих пор Backspase и скроллинг в консоли не работает ? Ставил недавно 6.0 - до сих пор драйвер териминала убогий.

> Бздя юникс, бздя юникс.....

> Стыдно вам должно быть.

> anonymous (*) (22.05.2006 18:24:28)

Хм... странно... Может я чего то не понимаю, но у меня с FreeBSD 4.какой-то там дремучей это работало. Сейчас вот 6.1 стоит. И что характерно - никаких танцев с бубнами :) и хороводов вокруг системника. Так как он очень далеко :)

>..а вот тут я не согласен с конечным выводом, пока не приведены конкретные >сравнения A с B.

да пожалуйста идем по вашей ссылке cvsweb..., тыкаем в первый попавшийся файл в kern:
kern_exec.c

/*
 * exec system call
 */
/* ARGSUSED */
int
sys_execve(struct lwp *l, void *v, register_t *retval)
{
struct sys_execve_args /* {
syscallarg(const char *)path;
syscallarg(char * const *)argp;
syscallarg(char * const *)envp;
} */ *uap = v;

return execve1(l, SCARG(uap, path), SCARG(uap, argp),
    SCARG(uap, envp), execve_fetch_element);
}

и 

int
execve1(struct lwp *l, const char *path, char * const *args,
    char * const *envs, execve_fetch_element_t fetch_element)
{
interror;
u_inti;
struct exec_packagepack;
struct nameidatanid;
struct vattrattr;
struct proc*p;
kauth_cred_tcred;
char*argp;
char*dp, *sp;
longargc, envc;
size_tlen;
char*stack;
struct ps_stringsarginfo;
struct ps_strings*aip = &arginfo;
struct vmspace*vm;
char**tmpfap;
intszsigcode;
struct exec_vmcmd*base_vcp;
intoldlwpflags;
#ifdef SYSTRACE
intwassugid = ISSET(p->p_flag, P_SUGID);
charpathbuf[MAXPATHLEN];
size_tpathbuflen;
#endif /* SYSTRACE */

/* Disable scheduler activation upcalls. */
oldlwpflags = l->l_flag & (L_SA | L_SA_UPCALL);
if (l->l_flag & L_SA)
l->l_flag &= ~(L_SA | L_SA_UPCALL);

p = l->l_proc;
/*
 * Lock the process and set the P_INEXEC flag to indicate that
 * it should be left alone until we're done here.  This is
 * necessary to avoid race conditions - e.g. in ptrace() -
 * that might allow a local user to illicitly obtain elevated
 * privileges.
 */
p->p_flag |= P_INEXEC;

cred = p->p_cred;
base_vcp = NULL;
/*
 * Init the namei data to point the file user's program name.
 * This is done here rather than in check_exec(), so that it's
 * possible to override this settings if any of makecmd/probe
 * functions call check_exec() recursively - for example,
 * see exec_script_makecmds().
 */
#ifdef SYSTRACE
if (ISSET(p->p_flag, P_SYSTRACE))
systrace_execve0(p);

error = copyinstr(path, pathbuf, sizeof(pathbuf),
  &pathbuflen);
if (error)
goto clrflg;

NDINIT(&nid, LOOKUP, NOFOLLOW, UIO_SYSSPACE, pathbuf, l);
#else
NDINIT(&nid, LOOKUP, NOFOLLOW, UIO_USERSPACE, path, l);
#endif /* SYSTRACE */

/*
 * initialize the fields of the exec package.
 */
#ifdef SYSTRACE
pack.ep_name = pathbuf;
#else
pack.ep_name = path;
#endif /* SYSTRACE */
pack.ep_hdr = malloc(exec_maxhdrsz, M_EXEC, M_WAITOK);
pack.ep_hdrlen = exec_maxhdrsz;
pack.ep_hdrvalid = 0;
pack.ep_ndp = &nid;
pack.ep_emul_arg = NULL;
pack.ep_vmcmds.evs_cnt = 0;
pack.ep_vmcmds.evs_used = 0;
pack.ep_vap = &attr;
pack.ep_flags = 0;

#ifdef LKM
lockmgr(&exec_lock, LK_SHARED, NULL);
#endif

/* see if we can run it. */
#ifdef VERIFIED_EXEC
        if ((error = check_exec(l, &pack, VERIEXEC_DIRECT)) != 0)
#else
        if ((error = check_exec(l, &pack, 0)) != 0)
#endif
goto freehdr;

/* XXX -- THE FOLLOWING SECTION NEEDS MAJOR CLEANUP */

/* allocate an argument buffer */
argp = (char *) uvm_km_alloc(exec_map, NCARGS, 0,
    UVM_KMF_PAGEABLE|UVM_KMF_WAITVA);
#ifdef DIAGNOSTIC
if (argp == NULL)
panic("execve: argp == NULL");
#endif
dp = argp;
argc = 0;

/* copy the fake args list, if there's one, freeing it as we go */
if (pack.ep_flags & EXEC_HASARGL) {
tmpfap = pack.ep_fa;
while (*tmpfap != NULL) {
char *cp;

cp = *tmpfap;
while (*cp)
*dp++ = *cp++;
dp++;

FREE(*tmpfap, M_EXEC);
tmpfap++; argc++;
}
FREE(pack.ep_fa, M_EXEC);
pack.ep_flags &= ~EXEC_HASARGL;
}

/* Now get argv & environment */
if (args == NULL) {
error = EINVAL;
goto bad;
}
/* 'i' will index the argp/envp element to be retrieved */
i = 0;
if (pack.ep_flags & EXEC_SKIPARG)
i++;

while (1) {
len = argp + ARG_MAX - dp;
if ((error = (*fetch_element)(args, i, &sp)) != 0)
goto bad;
if (!sp)
break;
if ((error = copyinstr(sp, dp, len, &len)) != 0) {
if (error == ENAMETOOLONG)
error = E2BIG;
goto bad;
}
#ifdef KTRACE
if (KTRPOINT(p, KTR_EXEC_ARG))
ktrkmem(l, KTR_EXEC_ARG, dp, len - 1);
#endif
dp += len;
i++;
argc++;
}

envc = 0;
/* environment need not be there */
if (envs != NULL) {
i = 0;
while (1) {
len = argp + ARG_MAX - dp;
if ((error = (*fetch_element)(envs, i, &sp)) != 0)
goto bad;
if (!sp)
break;
if ((error = copyinstr(sp, dp, len, &len)) != 0) {
if (error == ENAMETOOLONG)
error = E2BIG;
goto bad;
}
#ifdef KTRACE
if (KTRPOINT(p, KTR_EXEC_ENV))
ktrkmem(l, KTR_EXEC_ENV, dp, len - 1);
#endif
dp += len;
i++;
envc++;
}
}

dp = (char *) ALIGN(dp);

szsigcode = pack.ep_es->es_emul->e_esigcode -
    pack.ep_es->es_emul->e_sigcode;

/* Now check if args & environ fit into new stack */
if (pack.ep_flags & EXEC_32)
len = ((argc + envc + 2 + pack.ep_es->es_arglen) *
    sizeof(int) + sizeof(int) + dp + STACKGAPLEN +
    szsigcode + sizeof(struct ps_strings) + STACK_PTHREADSPACE)
    - argp;
else
len = ((argc + envc + 2 + pack.ep_es->es_arglen) *
    sizeof(char *) + sizeof(int) + dp + STACKGAPLEN +
    szsigcode + sizeof(struct ps_strings) + STACK_PTHREADSPACE)
    - argp;

len = ALIGN(len);/* make the stack "safely" aligned */

if (len > pack.ep_ssize) { /* in effect, compare to initial limit */
error = ENOMEM;
goto bad;
}

/* Get rid of other LWPs/ */
p->p_flag |= P_WEXIT; /* XXX hack. lwp-exit stuff wants to see it. */
exit_lwps(l);
p->p_flag &= ~P_WEXIT;
KDASSERT(p->p_nlwps == 1);

/* This is now LWP 1 */
l->l_lid = 1;
p->p_nlwpid = 1;

/* Release any SA state. */
if (p->p_sa)
sa_release(p);

/* Remove POSIX timers */
timers_free(p, TIMERS_POSIX);

/* adjust "active stack depth" for process VSZ */
pack.ep_ssize = len;/* maybe should go elsewhere, but... */

/*
 * Do whatever is necessary to prepare the address space
 * for remapping.  Note that this might replace the current
 * vmspace with another!
 */
uvmspace_exec(l, pack.ep_vm_minaddr, pack.ep_vm_maxaddr);

/* record proc's vnode, for use by procfs and others */
        if (p->p_textvp)
                vrele(p->p_textvp);
VREF(pack.ep_vp);
p->p_textvp = pack.ep_vp;

/* Now map address space */
vm = p->p_vmspace;
vm->vm_taddr = (caddr_t) pack.ep_taddr;
vm->vm_tsize = btoc(pack.ep_tsize);
vm->vm_daddr = (caddr_t) pack.ep_daddr;
vm->vm_dsize = btoc(pack.ep_dsize);
vm->vm_ssize = btoc(pack.ep_ssize);
vm->vm_maxsaddr = (caddr_t) pack.ep_maxsaddr;
vm->vm_minsaddr = (caddr_t) pack.ep_minsaddr;

/* create the new process's VM space by running the vmcmds */
#ifdef DIAGNOSTIC
if (pack.ep_vmcmds.evs_used == 0)
panic("execve: no vmcmds");
#endif
for (i = 0; i < pack.ep_vmcmds.evs_used && !error; i++) {
struct exec_vmcmd *vcp;

vcp = &pack.ep_vmcmds.evs_cmds[i];
if (vcp->ev_flags & VMCMD_RELATIVE) {
#ifdef DIAGNOSTIC
if (base_vcp == NULL)
panic("execve: relative vmcmd with no base");
if (vcp->ev_flags & VMCMD_BASE)
panic("execve: illegal base & relative vmcmd");
#endif
vcp->ev_addr += base_vcp->ev_addr;
}
error = (*vcp->ev_proc)(l, vcp);
#ifdef DEBUG_EXEC
if (error) {
int j;

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

вариант linux:

/*
 * sys_execve() executes a new program.
 */
asmlinkage int sys_execve(struct pt_regs regs)
{
	int error;
	char * filename;

	filename = getname((char __user *) regs.ebx);
	error = PTR_ERR(filename);
	if (IS_ERR(filename))
		goto out;
	error = do_execve(filename,
			(char __user * __user *) regs.ecx,
			(char __user * __user *) regs.edx,
			&regs);
	if (error == 0) {
		task_lock(current);
		current->ptrace &= ~PT_DTRACE;
		task_unlock(current);
		/* Make sure we don't return using sysenter.. */
		set_thread_flag(TIF_IRET);
	}
	putname(filename);
out:
	return error;
}

и 

/*
 * sys_execve() executes a new program.
 */
int do_execve(char * filename,
	char __user *__user *argv,
	char __user *__user *envp,
	struct pt_regs * regs)
{
	struct linux_binprm *bprm;
	struct file *file;
	int retval;
	int i;

	retval = -ENOMEM;
	bprm = kzalloc(sizeof(*bprm), GFP_KERNEL);
	if (!bprm)
		goto out_ret;

	file = open_exec(filename);
	retval = PTR_ERR(file);
	if (IS_ERR(file))
		goto out_kfree;

	sched_exec();

	bprm->p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);

	bprm->file = file;
	bprm->filename = filename;
	bprm->interp = filename;
	bprm->mm = mm_alloc();
	retval = -ENOMEM;
	if (!bprm->mm)
		goto out_file;

	retval = init_new_context(current, bprm->mm);
	if (retval < 0)
		goto out_mm;

	bprm->argc = count(argv, bprm->p / sizeof(void *));
	if ((retval = bprm->argc) < 0)
		goto out_mm;

	bprm->envc = count(envp, bprm->p / sizeof(void *));
	if ((retval = bprm->envc) < 0)
		goto out_mm;

	retval = security_bprm_alloc(bprm);
	if (retval)
		goto out;

	retval = prepare_binprm(bprm);
	if (retval < 0)
		goto out;

	retval = copy_strings_kernel(1, &bprm->filename, bprm);
	if (retval < 0)
		goto out;

	bprm->exec = bprm->p;
	retval = copy_strings(bprm->envc, envp, bprm);
	if (retval < 0)
		goto out;

	retval = copy_strings(bprm->argc, argv, bprm);
	if (retval < 0)
		goto out;

	retval = search_binary_handler(bprm,regs);
	if (retval >= 0) {
		free_arg_pages(bprm);

		/* execve success */
		security_bprm_free(bprm);
		acct_update_integrals(current);
		kfree(bprm);
		return retval;
	}

out:
	/* Something went wrong, return the inode and free the argument pages*/
	for (i = 0 ; i < MAX_ARG_PAGES ; i++) {
		struct page * page = bprm->page[i];
		if (page)
			__free_page(page);
	}

	if (bprm->security)
		security_bprm_free(bprm);

out_mm:
	if (bprm->mm)
		mmdrop(bprm->mm);

out_file:
	if (bprm->file) {
		allow_write_access(bprm->file);
		fput(bprm->file);
	}

out_kfree:
	kfree(bprm);

out_ret:
	return retval;
}

вполне хватило lor ограничений на длину коментария и главное практически все понятно, в отличие от...

> вариант linux:
[snip]
> вполне хватило lor ограничений на длину коментария и главное практически все понятно, в отличие от...

...само-собой, если не брать в рассчет таких мелочей, как open_exec(), sched_exec() etc и забавного факта, что в варианте NetBSD порядка 1/3 кода - это комментарии. подробные. в то время как в варианте Linux их попросту нет. как класса.

что, впрочем, не означает, что мне сильно нравится текущая реализация kern_exec() в NetBSD и все-таки с точки зрения компоновки кода это явно весьма так себе.

ps: нет, я конечно же понимаю, "все и так понятно so &*%^$ там коментировать?! да и ващще настоящие хакеры не пользуются документацией и коментариями!" and so on :) такие вот они аскеты - эти настоящие хакеры..

// wbr

>что, впрочем, не означает, что мне сильно нравится текущая реализация >kern_exec() в NetBSD и все-таки с точки зрения компоновки кода это явно >весьма так себе.

К сожалению "exec" это не едиственный пример, весь "kern" каталог наполнен кодом такого качества.

>ps: нет, я конечно же понимаю, "все и так понятно so &*%^$ там >коментировать?!

Именно, странно почему приходится объяснять такие очевидные вещи не junior разработчику: коментарии должны стоять только там где они действительно необходимы, коментарии типа
/*а здесь мы складываем a и b */
i = a + b;
только затрудняют чтение. 

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

В реализации запутанных алгоритмов, ну напрмер в коде ext3 вы найдете кучу коментариев.

>Во-во-во. Я про этот костыль и говорил. В стиле бздунов - сделать отвратительную реализацию ната и через 10 лет прихреначить сбоку нетграф...

Хех, посмотрим через год-два как эту разработку перекозлят линупсоиды и потом будут кричать на ЛОРе, что они самые крутые перцы...

> P.P.S. Яндех - Linux на базе Debian

Маме своей сказки рассказывай... на серверах поиска повально стоит FreeBSD, а Debian они только как пол-года назад начали активно использовать (в каких целях не известно)

> на своей машине не могу могу установить FreeBSD 6.1... линукс ставиться без проблем ...
>I_one # (*) (23.05.2006 13:14:19)

Поздравляю! Вы только что подтвердили что вы зеленый дендромутант с ластами растущими из жопы! Рук и мозгов у этого видв увы совсем нет :(

>Нормальные люди русифицируют ВСЁ ВСЕГДА и ПОД ЛЮБОЙ СИСТЕМОЙ через РУСИФИКАЦИЮ ИКСОВ!!! Вали в ФАК если ты этого ещё не знал, уважаемый!!! После ЧЕЛОВЕЧАЧЕЙ русификации у тебя работает кириллица, везде, как в кде, так и в любом приложении, где есть кириллические шрифты, а также в любом оконном менеджере. И кде здесь как было не при чём, так и осталось.

Начнем с простого - херли ты разорался, балаболка?

Не работала стандартная руссификация иксов. Если бы только у меня - проблем бы не было. Но не работала она и у других. Методом шаманства я припомнил как я это делал еще в 8-й мандряке и просто перебил таблицу раскладок. Тогда оно заработало. Причем именно в KDE. Почему-то остальные менеджеры работали с русификацией.

Что сделали BSD-шники с KDE в 5.1 - хз.

И при чем тут шрифты, когда не работало человеческое переключение клавиатуры? Шрифты и локаль - это одно. Поддержка доп.раскладок - это другое.

Что касается фака - я один из них писал, чудило. И проверил все варианты.

>как тебе это ни странно покажется, во всех UNIX-like одни и те же

Да ты еще и ламо воинствующее. А ты в курсе различий прописывания раскладок между xfree 4.2.0 и xfree 4.3.0? Думаю, что нет.

>"Сразу", имеется в виду когда хочу какой - тот и запускаю.

Гм. А я сидел всегда в одном каком-то менеджере, пока не перешел через два с половиной года на KDE.

>Флакбокс поддерживает большую функциональность, но не стабилен как блэкбокс

Валится? Никогда такого не видел. Просидел под ним полгода.

>и не поддерживает такие хоткейсы как новейший bbkeys. Либо поддерживает, но у меня ещё ни разу они не заработали.

Что же ты не валишь в фак? Воспользуйся своим советом.

>А ты не знал, что у фрибсд все порты - свои, как и пакеты? Типа, они сами своё кде с нуля пишут, свои боксы и т.д.и т.п.?

Вот поэтому переключение клавы и не заработало в KDE через иксы сразу и прямо.

>сложнее чем поднять сервер

Ну если настроить таблицы роутинга и файрволл написать - это поднять сервер, то извините. Уровень понятен.

>работают.

>Здесь как раз аргумент в том, что это всё одинаково хорошо работает под любой системой.

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

>Во многих дистрибах линукса бардак в /etc.

>Это мне сказали те, кто сами сидят под линуксом

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

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

Их можно поменять после установки. Или ты сразу лезешь со свежей машины куда-то?

>Да, пишу. Ссылки дать? Английский знаешь?

;)

Смешно. Очень.

>Что значит "слушаю"?

Перечитывай что пишешь.

>Почти в любом обсуждении о безопасности или интервью вспоминают OpenBSD

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

Мдэ 8) ... Хуже красноглазых линуксоидов только бздуны-фанатики, а хуже них только ссаныч 8)

> Именно, странно почему приходится объяснять такие очевидные вещи не junior разработчику: коментарии должны стоять только там где они действительно необходимы,

теоретически, чисто теоретически. и понятие "там, где действительно нужны" более чем субъективно. при наличии качественной документации на систему - вполне возможно. при ее отсутствии - как минимум 50% кода есть комментарии, чтобы осталось хоть что-то осталось последователям.

но это лишь мое личное мнение. если у вас оно отлично от моего - нет проблем, "каждый человек сам творец своих проблем" (c) FIDO.

> коментарии типа /*а здесь мы складываем a и b */ i = a + b; только затрудняют чтение.

не утрируйте

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

может быть, может быть. у меня не стояло цели кого-то в чем-то переубедить. это был обычный забавный флуд при наличии желания на тот момент времени. каждый остался при своем мнении и это нормально. иначе в сущьности и быть не могло [IMHO даже теоретически].

> В реализации запутанных алгоритмов, ну напрмер в коде ext3 вы найдете кучу коментариев.

в другой раз, господа, как-нибудь в другой раз :)
the flame is over, работать пора. cu.

// wbr