Используя многоуровневые из модулей ядра для взаимодействия через интерфейс с устройством?
Хорошо, я получил частичный ответ, обходное решение, на основе этого журнала отчета об ошибках, я нашел. Я могу загрузиться после изменения корня аргументов ядра начальной загрузки личинки к root=/dev/mapper/base-root и добавление rootdelay=1 позволяет мне загрузиться к моей системе. Yay!
Как я делаю эти изменения постоянными, и являюсь там какими-либо действительными решениями этой ошибки уже?
What в чем причина реализации структуры «стека модулей ядра»?
Именно так написано почти все программное обеспечение в модульных стеках. Рассмотрим свой графический интерфейс: в нем задействованы все компоненты пространства ядра, включая стек драйверов, затем в пользовательском пространстве у вас есть X-сервер, и, кроме того, диспетчер окон, и, возможно, среда рабочего стола, и поверх этого ( например) ваш браузер.
Причина довольно проста: рассмотрим ситуацию, если бы такого стека пользовательского пространства не было. Каждое приложение с графическим интерфейсом пользователя должно было бы написать свой собственный код, взаимодействующий с ядром для доступа к экрану и т.д. вещи, и почти никто не стал бы писать что-либо из-за огромного объема работы.
То же самое и с модулями ядра. Изделие, которое можно использовать более чем для одной цели, должно быть независимым. Таким образом, WRT для USB-устройств, вместо того, чтобы каждый драйвер должен встраивать в себя драйвер для USB-контроллера, у вас есть один драйвер для контроллера и отдельные драйверы устройств, взаимодействующие с ним.
Разве это не усложняет процесс?
Нет, это сильно его упрощает. Правда, у вас может быть задействовано 3 модуля вместо одного, но если бы был только один, в любом случае пришлось бы реализовать то, что реализуют другие два.
У модульной конструкции много преимуществ, и она является основным элементом разработки программного обеспечения. Сильная модульность необходима, чтобы избежать греха чрезмерной связи . Я уверен, если вы спросите любого, кто потратил много времени на программирование, что по мере того, как они совершенствовались в этом и становились более компетентными в более крупных и сложных проектах, они становились все более и более модульными в своей работе, т.е. вырос, чтобы писать более мелкие и дискретные произведения. Это означает осознание того, что вам будет лучше с 3 частями вместо 1, когда это имеет смысл (поиск «там, где это имеет смысл» является частью навыка - чем больше мест вы можете увидеть, тем лучше). 1
Если это кажется нелогичным, подумайте, что произойдет, если модуль, bigfoobar , неправильно себя ведет, указывая на ошибку.Выяснить, где он находится, будет намного проще, если он на самом деле состоит из трех меньших частей, потому что вы можете независимо протестировать big , foo и bar , чтобы определить, кто из них виноват. Кроме того, foo может иметь общее применение в другом месте (например, как часть altfoothing , но обратите внимание, что соглашения об именах в действительности так не работают). Чем больше мест foo используется, тем большему количеству контекстов он подвергается и тем более надежным (функциональным, эффективным, свободным от ошибок) он может оказаться.
1. Чем дальше вы заглянете в стек, тем больше узнаете, что он состоит из регрессии других стеков все меньшего и меньшего масштаба. 90% (не цитируйте меня) кода пользовательского пространства, выполняемого вашим процессором, на самом деле является частью собственной библиотеки C, которая является относительно небольшим исполняемым файлом. Это часть того, что позволяет эффективно запускать широкий спектр сложного программного обеспечения, потому что все состоит из одних и тех же маленьких кусочков. Подумайте о лего и разнице между 5 большими блоками и 50 меньшими.
Рассмотрим, например, USB-накопитель. Есть модуль, который обменивается данными с USB (взаимодействует с реальным оборудованием), уровень, обрабатывающий его как блочное устройство SCSI, общая обработка блочных устройств; а затем слой, обрабатывающий фактическую файловую систему, которая организует данные на диске. Большинство из них могут быть настоящими модулями ядра Linux. Другие слои являются фиксированными, но, тем не менее, отдельными.
Если смотреть на это изолированно, это действительно выглядит излишеством. Но у него есть несколько преимуществ: во-первых, если вы рассмотрите концептуальное расстояние между «Дайте мне первые 50 байтов файла foo.txt на устройстве» и «Переключите эти контакты точно так, чтобы» вы увидели нужно разделить это на более мелкие шаги, чтобы понять это. Во-вторых, что гораздо более важно для операционных систем в целом, это то, что, разрезая стек таким образом, вы можете использовать точно такую же организацию данных на вашем флеш-накопителе, гибком диске или различных жестких дисках. Если появляется другая файловая система, вы можете снова смешивать и сопоставлять. То же самое и с новыми типами устройств (USB - относительный новичок в Linux, эта организация упростила (для некоторого странного значения слова «easy», конечно) их беспрепятственное добавление).