Вопросы Теги

Как sbrk/brk реализованы в Linux?

У меня была такая же ситуация, когда я пытался настроить среду Visual Studio Professional 2017 с MySQL, ADO.NET (Database First) и EF6.

Примечание. Пожалуйста, следуйте инструкциям в том же порядке.

  1. Удалите / удалите «Connector / NET» и «MySQL для Visual Studio», если установлены.

  2. Установите «MySQL для Visual Studio» v2.0.5 CTP ( MySQL для Visual Studio ). Примечание. Установите MySQL для Visual Studio перед соединителем / NET.

  3. Установите «Connector / NET» v6.9.10 ( Connector / Net ). https://i.stack.imgur.com/XOT1I.jpg Примечание. Сначала я попытался использовать Connector / NET v6.8, v6.10 и v8, но ни один из них не работал с Visual Studio 2017 и ADO.Net. Здесь вы можете найти все версии и совместимости Connector с IDE Visual Studio , но пока этот список неточен.

  4. Создать новый проект Visual Studio Professional 2017.

  5. Загрузите и установите «EntityFramework» v6.2.0 через NuGet, перейдя на вкладку «Проект» / «Управление пакетами NuGet» / «Обзор» -> Entity Framework.

  6. Добавить ссылки на C:\Program Files (x86)\MySQL\Connector.NET 6.9.10\Assemblies\v4.5\MySql.Data.dll и C:\Program Files (x86)\MySQL\Connector.NET 6.9.10\Assemblies\v4.5\MySql.Data.Entity.EF6.dll; щелкнув правой кнопкой мыши по ссылкам в обозревателе решений и выбрав Добавить ссылку / Обзор -> кнопку Обзор.

  7. Добавить информацию о поставщике MySQL EF6 в App.config в соответствии с поставщиками инфраструктуры объектов следующим образом:
  1. Перестройте проект, перейдя на вкладку «Сборка» / «Перестроить имя проекта».

И это все. VS2017 готов к работе. Надеюсь, что это работает для всех, как и для меня сегодня.

Ссылки :

  1. Невозможно создать модель данных объекта - с использованием MySql и EF6

  2. Не найден поставщик Entity Framework для поставщика ADO.NET «MySql.Data.MySqlClient»

19
задан samoz 15 June 2009 в 17:50
поделиться

4 ответа

В представлении очень высокого уровня ядро ​​Linux отслеживает память, видимую процессу, как несколько «областей памяти» ( struct vm_area_struct ). Существует также структура, которая представляет (опять же на очень высоком уровне) все адресное пространство процесса ( struct mm_struct ). Каждый процесс (за исключением некоторых потоков ядра) имеет ровно одну struct mm_struct , которая, в свою очередь, указывает на все struct vm_area_struct для памяти, к которой он может получить доступ.

sys_brk Системный вызов (находится в mm / mmap.c ) просто настраивает некоторые из этих областей памяти. ( sbrk - это оболочка glibc вокруг brk ).

23
ответ дан 30 November 2019 в 02:48
поделиться

Ключевой концепцией того, как ядро ​​Linux передает память пользовательскому процессу, является то, что доступная куча процессов (сегмент данных) увеличивается снизу. ядро не отслеживает отдельные фрагменты памяти, а только непрерывный блок памяти. системные вызовы brk / sbrk увеличивают объем памяти, имеющейся у процесса, но процесс может управлять ею по частям.

Ключевым последствием этого является то, что память, разбросанная по адресному пространству процессов, которая не используется не может быть возвращен в операционную систему для других целей. Операционной системе может быть возвращена только память в самом конце сегмента данных, поэтому используемую память ближе к концу нужно будет сместить вниз к вершине. На практике этого почти не делают распределители. По этой причине это '

2
ответ дан 30 November 2019 в 02:48
поделиться

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

4
ответ дан 30 November 2019 в 02:48
поделиться

вы должны понять, как работает виртуальная память и как отображение MMU соотносится с реальной RAM.

реальная RAM делится на страницы, обычно по 4 КБ каждая. каждый процесс имеет свое собственное отображение MMU, которое представляет этому процессу линейное пространство памяти (4 ГБ в 32-разрядном Linux). конечно, не все из них фактически выделены. сначала он почти пустой, то есть с большинством адресов не связана никакая реальная страница.

когда процесс достигает невыделенного адреса (пытается прочитать, записать или выполнить его), MMU генерирует ошибку (аналогично прерывание), и вызывается система ВМ. Если он решает, что там должна быть некоторая RAM, он выбирает неиспользуемую страницу RAM и связывается с этим диапазоном адресов.

Таким образом, ядро ​​не заботится о том, как процесс использует память, и процессу на самом деле все равно, как много оперативной памяти есть, он всегда будет иметь одинаковые линейные 4 ГБ адресного пространства.

теперь brk / sbrk работают на несколько более высоком уровне: в принципе, любой адрес памяти «за» этой меткой недействителен и не будет получить страницу RAM при доступе, вместо этого процесс будет убит. библиотека пользовательского пространства управляет выделением памяти в пределах этого лимита и только при необходимости просит ядро ​​увеличить ее.

Но даже если процесс запускается установкой brk на максимально допустимое значение, это не будет реально Страницы ОЗУ выделяются до тех пор, пока не начнется доступ ко всем адресам памяти.

вместо этого процесс будет убит. библиотека пользовательского пространства управляет выделением памяти в пределах этого лимита и только при необходимости просит ядро ​​увеличить ее.

Но даже если процесс запускается установкой brk на максимально допустимое значение, это не будет реально Страницы ОЗУ выделяются до тех пор, пока не начнется доступ ко всем адресам памяти.

вместо этого процесс будет убит. библиотека пользовательского пространства управляет выделением памяти в пределах этого лимита и только при необходимости просит ядро ​​увеличить ее.

Но даже если процесс запускается установкой brk на максимально допустимое значение, это не будет реально Страницы ОЗУ выделяются до тех пор, пока не начнется доступ ко всем адресам памяти.

18
ответ дан 30 November 2019 в 02:48
поделиться
Другие вопросы по тегам:

Похожие вопросы: