Исходное сообщение
"Изменение подсистем драйверов, USB и PCI в Linux ядре 2.6.24..." Отправлено _Nick_, 30-Сен-07 22:32
> Проверялся. =) ну а результат какой ? ;)) отлично. тогда, предположим, что API драйверов некого ядра содержит 3 вызова. Так, для наглядности. Давай на таком API подымем самое простое - линуховый ext2. вот структура его операций: static const struct super_operations ext2_sops = {         .alloc_inode    = ext2_alloc_inode,         .destroy_inode  = ext2_destroy_inode,         .read_inode     = ext2_read_inode,         .write_inode    = ext2_write_inode,         .put_inode      = ext2_put_inode,         .delete_inode   = ext2_delete_inode,         .put_super      = ext2_put_super,         .write_super    = ext2_write_super,         .statfs         = ext2_statfs,         .remount_fs     = ext2_remount,         .clear_inode    = ext2_clear_inode,         .show_options   = ext2_show_options, #ifdef CONFIG_QUOTA         .quota_read     = ext2_quota_read,         .quota_write    = ext2_quota_write, #endif }; итого, с квотами это 14 вызовов. ТеперЪ мы имеем делеммму: - пойти простым путем и постоянно передавать указатель на эту структура-монстра через какой-нить доп. параметр имеющегося API, либо - все-же изменить API, учтя требования для _человеческой_ реализации подобной сложности файловых систем. Потому как вдальнейшем нам захочеться добавить такую не одну (jfs, reiser, lustre....) Каким путем пойдем, тАварищи?? Пример с API на 3 функции и задачей реализовать 14 можно легко экстраполировать в рекущие размеры API и то, что может быть придумано в будущем. Кому-то еще непонятно, что изменения API - это нормальный процесс?

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
	Введите код, изображенный на картинке: