Обзор ядер UNIX вообще и HP-UX в частности

Ответ на: комментарий от anonymous 12.07.04 14:38:54 MSD

> возьми любую книгу по C и прочитай, зачем там оставлен goto

Чтобы Basic программисты чувствовали себя комфортно? ;-)

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

Кроме того, более 4 вложенных циклов не есть пример хорошего кодирования. Ты ещё скажи что несколько return в теле функции это нормально. А потом приходяят проблемы с мемори ликами, блокировками и т.д.

alman ★★★
(12.07.04 15:15:21 MSD)

Ответ на: комментарий от alman 12.07.04 15:15:21 MSD

> Ты ещё скажи что несколько return в теле функции это нормально. А потом приходяят проблемы с мемори ликами, блокировками и т.д.

Ну конечно, монструозные конструкции из операторов if() гораздо лучше.

anonymous
(12.07.04 15:32:12 MSD)

Ответ на: комментарий от anonymous 12.07.04 15:32:12 MSD

>> Ты ещё скажи что несколько return в теле функции это нормально. А потом приходяят проблемы с мемори ликами, блокировками и т.д. 

>Ну конечно, монструозные конструкции из операторов if() гораздо лучше.

Эти монстрообразные if() легко обходятся с помощью нижеприведённой конструкции.

int sample(some_arg)
{
   int Status;

   acquire_resources();

   do {

      Status = some_func(some_arg);
      if(Status<0)
      {
         // Bla-bla-bla
         break;
      }

      Stauts = another_func(some_arg);
      if(Status<0)
      {
          // Bla-bla-blad
          break;
      }

   } while(0);

   release_resources();

   return Status;
}

alman ★★★
(12.07.04 15:52:50 MSD)

Ответ на: комментарий от alman 12.07.04 15:52:50 MSD

> Эти монстрообразные if() легко обходятся с помощью нижеприведённой конструкции.

На что только не пойдут люди, лишь бы избавиться от страшного слова goto :)

anonymous
(12.07.04 16:03:01 MSD)

Ссылка

Ответ на: комментарий от alman 12.07.04 15:52:50 MSD

> Эти монстрообразные if() легко обходятся с помощью нижеприведённой конструкции.

Прелестно. Использовали break, как неявный goto. Очень способствует читабельности. И чем это лучше такого кода например:

rc = pci_enable_device(pdev);
if (rc)
goto err_out_free;

rc = pci_set_mwi(pdev);
if (rc)
goto err_out_disable;

rc = pci_request_regions(pdev, DRV_NAME);
if (rc)
goto err_out_mwi;

anonymous
(12.07.04 16:07:02 MSD)

Ответ на: комментарий от anonymous 12.07.04 16:07:02 MSD

Блин, форматирование съехало :(

anonymous
(12.07.04 16:08:09 MSD)

Ссылка

Ответ на: комментарий от alman 12.07.04 15:15:21 MSD

> Дружище, в книгах написано что опреатор goto иногда полезен чтобы выйти из множества вложенных циклов, например по ошибке.

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

а единичный return это устаревшая догма (тем более для современных языков)

anonymous
(12.07.04 16:13:03 MSD)

Ответ на: комментарий от anonymous 12.07.04 13:33:57 MSD

>вот, еще одна статья про кривость Linux'a - сетевая подсистема: http://www.osp.ru/os/2001/12/077.htm

Лохматого года

Shaman007 ★★★★★
(12.07.04 16:35:18 MSD) автор топика

Ответ на: комментарий от anonymous 12.07.04 01:14:41 MSD

> Нет к разнообразию:
>
> generic_file_llseek
> no_llseek
> dcache_dir_lseek
> default_llseek
> seq_lseek

этот список можно продолжить. cpuid_seek, msr_seek, sound_lseek,
pfm_lseek, dev_nvram_llseek, remote_llseek, block_llseek, устал,
хватит. и что? линукс позволяют любому устройству или файловой
системе реализовать свой метод, считаете это плохо? я считаю, это
хорошо.

сама же функция sys_llseek() устроена очень просто. она вызывает
одноименный метод из f_op (считайте таблицей виртуальных функций),
или (если он не определен), метод "базового класса" generic_file_llseek.
не вижу, почему у вас были сложности с пониманием.

> > кстати, глядя на этот lseek() от OpenBSD сразу видно, что
> > SMP не поддерживается. я думал, они уже сделали?
>
> Сделали. А что Вы такое нашли, противоречащее этому?

противоречит все. что будет, если другой поток закроет файл после
fd_getfile() ? да что говорить, вот эта невинная строчка
        fp->f_offset = SCARG(uap, offset);

не может быть SMP safe. присваивание не атомарно на 32 битной машине,
если vfs поддерживает файлы больше 4Г. или в OpenBSD все syscalls
globally serialized, тогда это SMP на уровне linux 2.2.

alman wrote:
> А пока поищете в дереве исходников директиву goto.
> Кроме того расскажите, имел ли место первоначальный дизайн ядра?
> Кстати, в реализации Линукса lseek за конец файла действительно
> предотвращает дефрагментацию?
> Так вот, будут ли иноды этого файла фрагментированы или нет?
> Эти монстрообразные if() легко обходятся с помощью нижеприведённой
> конструкции.

все вот это в очередной раз доказывает, что люди, бросающиеся заявлениями,
что код linux/bsd/не_важно_что_еще плох (безо всякого повода, заметим,
ветка ведь совсем не об этом):

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

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

idle ★★★★★
(12.07.04 17:39:28 MSD)

Ответ на: комментарий от anonymous 12.07.04 16:13:03 MSD

>я всего лишь ответил на глупость о том, что goto "это прежде всего проблема программиста"

Не просто goto, а бесконтрольное использование goto. Хотя... это скорее всего проблема не программиста, а пользователя которому приходится пользоваться продуктом.

>а единичный return это устаревшая догма (тем более для современных языков)

С этого места подробнее, если можно. Неужели в С уже появились объекты и auto_ptr? Если мне память не изменяет, мы говорим о ядре и gcc на котором оно написано.

Каким образом компилятор может отследить пропущенное освобождение ресурсов? Поменяйте в примере выше break на return - вот и получится типичная проблема использования множественного return.

alman ★★★
(12.07.04 17:49:14 MSD)

Ответ на: комментарий от alman 12.07.04 17:49:14 MSD

Ты реально можешь месть показать, где из-за этого память текет?

Shaman007 ★★★★★
(12.07.04 17:52:18 MSD) автор топика

Ответ на: комментарий от idle 12.07.04 17:39:28 MSD

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

Напротив. Minix, Ext2, FAT, ISO9660, devfs, ramfs.

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

очень, очень веское заявление. Может быть похвастаесь своими разработками?

alman ★★★
(12.07.04 17:58:10 MSD)

Ответ на: комментарий от Shaman007 12.07.04 17:52:18 MSD

>Ты реально можешь месть показать, где из-за этого память текет?

Вообще-то могу: http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/0807.html

Последний changelog :)

Делаем поиск по словам leaking и broken

alman ★★★
(12.07.04 18:10:34 MSD)

Ссылка

Ответ на: комментарий от Shaman007 12.07.04 16:35:18 MSD

пардон, в Linux уже нет этого @#$~!@#%@#^ sk_buf?

anonymous
(12.07.04 18:22:38 MSD)

Ссылка

Ответ на: комментарий от alman 12.07.04 17:58:10 MSD

alman:
> > сами не сделали ничего, что было бы хотя бы в какой-то мере сопоставимо
> > с этим самым кодом.
>
> Напротив. Minix, Ext2, FAT, ISO9660, devfs, ramfs.

http://linux.bkbits.net:8080/linux-2.5/hist/fs/ramfs/inode.c?nav=index.html|src/
.|src/fs|src/fs/ramfs

видим: torvalds, akpm, viro, trond, Andries.Brouwer, hirofumi, hch.

кто из них Вы?

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

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

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

на всякий случай, у меня есть пара десятков принятых патчей, но я отнюдь
не считаю свой вклад в ядро сколько нибудь значительным. и мне вовсе не
"за державу обидно". точно также меня раздражают и те, кто вопит:
"Windows must die".

idle ★★★★★
(12.07.04 18:51:40 MSD)

Ответ на: комментарий от idle 12.07.04 18:51:40 MSD

>> Напротив. Minix, Ext2, FAT, ISO9660, devfs, ramfs.

>видим: torvalds, akpm, viro, trond, Andries.Brouwer, hirofumi, hch.

>кто из них Вы?

Я где-то сказал что участвовал в разработке ядра? Желаете ли Вы посмотреть мой код, который позволяет читать образы файловых систем Minix, Ext2, FAT, ISO9660?

>> очень, очень веское заявление. Может быть похвастаесь своими разработками?

>но ведь не более веское, чем обвинять Линуса или Мортона да и многих других в некомпетентности? вы ведь именно это делаете.

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

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

Ваша скромность делает Вам честь.

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

Ну вот, оказывается Вы заинтересованное лицо.

>и мне вовсе не "за державу обидно". точно также меня раздражают и те, кто вопит: "Windows must die".

Ну почемку же сразу маст дай? Линукс всё же работает. Только работает он не благодаря продуманному дизайну, а благодаря титанической работе тысяч программистов.

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

alman ★★★
(12.07.04 20:07:00 MSD)

Ссылка

Ответ на: комментарий от idle 12.07.04 17:39:28 MSD

> противоречит все. что будет, если другой поток закроет файл после

Там треды не ядерные, а юзерлэндовые.

anonymous
(13.07.04 10:50:52 MSD)

Ответ на: комментарий от anonymous 13.07.04 10:50:52 MSD

> Там треды не ядерные, а юзерлэндовые.

то есть, ядром не поддерживаются. в user-level
реализовать потоки вообще можно только до некоторой
степени, a SMP - вообще никак.

прежде, чем вы начнете мне обьяснять, что user-level
потоки, это здорово, посмотрите сюда:
http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/lib/libpthread/uthread/uthread_rea
d.c?rev=1.7

а как насчет присваивания? что будет, если child
входит в lseek() на другом процессоре? повторю, это
не SMP код. или все под bkl. я, кстати, описАлся,
говоря, что это на уровне linux 2.2, это 2.0.

OpenBSD (я говорю о ядре) замечательный продукт, но
сравнивать его с linux сегодня не очень интересно.
Он намного меньше/проще, что, конечно, не означает
хуже/лучше.

idle ★★★★★
(13.07.04 14:51:31 MSD)

Ответ на: комментарий от idle 13.07.04 14:51:31 MSD

> прежде, чем вы начнете мне обьяснять, что user-level
> потоки, это здорово,

Не не буду ;)

> OpenBSD (я говорю о ядре) замечательный продукт, но
> сравнивать его с linux сегодня не очень интересно.

Мне тоже абсолютно не интересно сравнивать OpenBSD и Linux. Да оно и
не зачем. Я просто говорю об отношению к написанию кода. Лишь только.
Мое imho, что, к примеру, в OpenBSD код написан _читабельнее_.

> а как насчет присваивания? что будет, если child
> входит в lseek() на другом процессоре?

Я этого не знаю. Я не kernel hacker. Мне в userlan работы по-уши ;)

anonymous
(13.07.04 18:28:15 MSD)

Ссылка

Ответ на: комментарий от idle 12.07.04 17:39:28 MSD

Да, еще:

> сама же функция sys_llseek() устроена очень просто. она вызывает
> одноименный метод из f_op (считайте таблицей виртуальных функций),
> или (если он не определен), метод "базового класса" 
> generic_file_llseek.
> не вижу, почему у вас были сложности с пониманием.

Я чего-то не допонял. По моему мы смотрим в разные версии ядер. Я
говорил про 2.4.22 (чуть старше на самом деле, но не суть). Вы
наверное имели в виду 2.6.

Я не нашел упоминаний о "она вызывает одноименный метод из f_op".

Вот, что вижу я:

#if !defined(__alpha__)
asmlinkage long sys_llseek(unsigned int fd, unsigned long offset_high,
                           unsigned long offset_low, loff_t * result,
                           unsigned int origin)
{
        int retval;
        struct file * file;
        loff_t offset;

        retval = -EBADF;
        file = fget(fd);
        if (!file)
                goto bad;
        retval = -EINVAL;
        if (origin > 2)
                goto out_putf;

        offset = llseek(file, ((loff_t) offset_high << 32) | offset_low,
                        origin);

        retval = (int)offset;
        if (offset >= 0) {
                retval = -EFAULT;
                if (!copy_to_user(result, &offset, sizeof(offset)))
                        retval = 0;
        }
out_putf:
        fput(file);
bad:
        return retval;
}
#endif

И кстати, а че там с альфой такое, что везде можно, а там низя?

anonymous
(13.07.04 18:31:46 MSD)

Ответ на: комментарий от anonymous 13.07.04 18:31:46 MSD

Да и еще. fget(fd) делает readlock, потом readunlock. Здесь тоже я
так понимаю должна быть вышеописаная проблема?

anonymous
(13.07.04 18:34:38 MSD)

Ответ на: комментарий от anonymous 13.07.04 18:34:38 MSD

> Мое imho, что, к примеру, в OpenBSD код написан _читабельнее_.

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

> Я не kernel hacker.

да я, в общем-то, тоже. так, иногда...

> Вы наверное имели в виду 2.6.

да, но они очень похожи...

> Я не нашел упоминаний о "она вызывает одноименный метод из f_op".

посмотрите выше код llseek() (не sys_llseek)

> И кстати, а че там с альфой такое, что везде можно, а там низя?

это мало не связана с ядром. проблема в связке с libc, нужно
передавать/возвращать 64 бит

> fget(fd) делает readlock, потом readunlock. Здесь тоже я
> так понимаю должна быть вышеописаная проблема?

нет, почему же.

struct file * fget(unsigned int fd)
{
        struct file * file;
        struct files_struct *files = current->files;

        read_lock(&files->file_lock);        <---- никто не сможет открыть/закрыть файл
        file = fcheck(fd);
        if (file)
                get_file(file);              <---- увеличен счетчик f_count
        read_unlock(&files->file_lock);      <---- файл может быть закрыт, но f_count не будет 0
        return file;
}

idle ★★★★★
(13.07.04 19:23:34 MSD)

Ответ на: комментарий от idle 13.07.04 19:23:34 MSD

> посмотрите выше код llseek() (не sys_llseek)

Да, тут видно. lock_kernel, unlock_kernel...

> > И кстати, а че там с альфой такое, что везде можно, а там низя?
>
> это мало не связана с ядром. проблема в связке с libc, нужно
> передавать/возвращать 64 бит

Странно... А для sparc64 получается нормально?...

> > fget(fd) делает readlock, потом readunlock. Здесь тоже я
> > так понимаю должна быть вышеописаная проблема?
>
> нет, почему же.

Тут тоже вроде ясно... 

Ладно. Будем держать хвост пистолетом ;)

anonymous
(14.07.04 01:21:45 MSD)

Ссылка

Похожие темы