tl;dr — Начните с объединенного ядра Linux и используйте поддержку OABI. Посмотрите, как это работает, а затем подумайте об объединении пользовательского пространства.
То, как вы сформулировали этот вопрос, делает его субъективным. На самом деле, просто дать ответ было бы. Рассмотрим некоторые факты. Во-первых, ответ будет зависеть от ваших целей и определенной организационной квалификации. Т.е. абсолютно правильного ответа ни для кого быть не может. Но если мы рассмотрим преимущества и недостатки, то для большинства все должно быть ясно.
Будут ли два микроконтроллера на базе ARM926EJ-S с разными размерами кэш-памяти совместимы?
Для аспекта генерации кода компилятора они почти наверняка на 100% идентичны. То есть у gcc не должно возникнуть проблем с генерацией кода для одного или другого. Однако есть более серьезные проблемы со сменой компилятора,
- Код, основанный на неопределенном поведении, может не работать.
- Код, использующий расширения компилятора, потребует переноса.
- Ошибки в компиляторе могут иметь обходные пути в исходном коде или вызывать некоторые скрытые дефекты при обновлении компилятора.
- Разница во времени может выявить условия гонки у очень плохих гонщиков.
Будет ли пересборка цепочки инструментов и ядра для этих микроконтроллеров полезной и сэкономит время разработки в будущем?
Конечно, это зависит. Linux 2.6.31.5 не является стабильным ядром (т. е. не имеет исправлений сообщества), в отличие от Linux 2.6.32.65. Если поставщик не предоставляет дерево git, невозможно трудно сказать, что было/не было применено к этому дереву. Так что поддержка этой старой версии Linux, вероятно, является большой задачей. То есть исправления безопасности, обновления подсистем и общие ошибки. Если вам нужно поддерживать пользовательские драйверы на обеих платформах, аналогичный API для Linux будет несомненной победой. Если вы используете только ядра Linux поставщика и не имеете полномочий для их поддержки/изменения, это может исказить проблему.
3.16 — более современный Linux. Тем не менее, он также не будет иметь поддержки сообщества. 3.14 или 3.18 в настоящее время являются долгосрочными. Безусловно, обновление до версии 3.18 и использование дерева драйверов/устройств поставщиков из версии 3.16 — довольно простая задача. Таким образом, главный вопрос ядра Linux будет заключаться в следующем:
- Поддерживают ли оба ядра поставщик A и поставщик B?
- Сколько пользовательского кода/драйверов они предоставляют.
- Каковы ваши внутренние или внешние компетенции ядра?
- У вас есть собственные драйверы?
- Будете ли вы обновлять оборудование до новых чипсетов в будущем?
- Срок службы чипсетов.
- Использует ли продукт подсистемы iptables, usb и т. д. в Linux?
По моему опыту, ответ на 1 (для любого поставщика) — НИКОГДА!. Люди, поддерживающие это, перегружены работой, и компания не даст им времени, чтобы сделать все как следует. Пункты 4-6 укажут на слияние ядер. Поддержка вещей на нескольких ядрах болезненна. Не только для написания кода, но и для тестирования. Также возможно иметь один и тот же двоичный файл, поддерживающий обе платформы, что может принести другие преимущества.
Что касается цепочки инструментов, у вас есть проблемы в первом вопросе, с которыми нужно бороться за пользовательское пространство. Однако ядра Linux должны хорошо работать с различными компиляторами. Существуют различные проверки совместимости компилятора. Кроме того, современные ядра Linux поддерживают как OABI, так и EABI. Таким образом, вполне возможно объединить ядро Linux, сохраняя при этом отдельное пользовательское пространство.
Учитывая эту информацию, вы бы решили перестроить цепочки инструментов и ядра или продолжили бы работу с отдельными цепочками инструментов, доступными сейчас?
Это мнение, как сейчас сформулировано. Крайне маловероятно, что поддержка поставщика так же хороша, как и сообщество. Однако, если у вас нет опыта работы с ядрами и/или драйверами, И вы предполагаете, что аппаратное обеспечение никогда не изменится, вы можете придерживаться предоставленных ядер Linux. Возможно, в вендоре Linux есть скрытые функции, связанные с инициализацией DDR и другими аппаратными странностями, которые никогда не попадали в основную линейку. Наличие исходного кода для этих ядер полезно.
Кажется, вы никогда не будете производить и модифицировать свое оборудование. То есть, вы используете только готовое оборудование и никогда не используете такие вещи, как iptable/nftables и т. д., поддержка поставщика сносная, и вы (организация) не компетентны в программировании драйверов/ядра, тогда может имеет смысл остаться на месте.
В противном случае инструменты git и поддержка сообщества могут сделать обновление ядра довольно простым даже при наличии небольшой компетенции. Вы также можете обратиться к поставщику с просьбой обновить код, если ваши объемы достаточно велики, или нанять консультанта, который сделает перенос для вас. Наверняка, если вы пишете собственный код ядра, объединенные ядра сократят объемы тестирования, кодирования и помогут с автоматическим тестированием и инструментами.
Если вы объединяете ядра, то объединение пользовательского пространства имеет больше смысла. Несмотря на то, что пользовательское пространство может быть одним и тем же кодом/компилятором, разные ядра Linux будут влиять на поведение во время выполнения. В конечном счете, объединенную кодовую базу легче поддерживать. Вопрос в том, перевешивают ли усилия, направленные на достижение этого результата, преимущества этого достижения? Это зависит от проекта и организации.
person
artless noise
schedule
20.04.2015
