It was 2am and I was being 'trolled'/abused for my lack of enthusiasm and
support for Linux, I regret it spilled over in my reply for a completely
different subject.

I'm pacifist and it was by no means supposed to be harsh and should not have
been directed at others about an unrelated subject.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Sven Barth
Sent: Thursday, 7 April 2011 3:14 PM
To: [email protected]
Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode call for
syslog(2) analog in ROS

Am 06.04.2011 23:20, schrieb dmex:
> -And that's why I suggested a device driver... so one can add once own 
> "extensions" without sacrificing compatibility :)
>
> That could work, It could read or write the 'DBWIN_BUFFER' file and 
> allow a replacement driver to support outputs using other methods.
>
> I also apologize for my last e-mail, It was very harsh, totally 
> unwarranted and uncalled for.
>

Seems like your "harshness" didn't come along as you "wanted" it to... 
Or perhaps I was to tired to recognize that it was meant in a harsh way...
^^

Regards,
Sven

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> On Behalf Of Sven Barth
> Sent: Thursday, 7 April 2011 5:10 AM
> To: [email protected]
> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode 
> call for
> syslog(2) analog in ROS
>
> On 06.04.2011 22:53, dmex wrote:
>> DebugPring/OutputDebugString would be a good place to start learning 
>> how Windows outputs kernel messages ;) 
>> http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-ap
>> i
>> -works
>> /
>>
>> ReactOS OutputDebugString Source:
>> http://doxygen.reactos.org/da/def/dll_2win32_2kernel32_2debug_2output
>> _
>> 8c_a94
>> 90feb381d7062ca6e5a28bdeacd6d2.html
>>
>
> I'll put that on my todo list once I have a few minutes :D
>
>> Minas's idea is terrible in my opinion, "Do we need special system 
>> call like Linux, or even more, the whole family of them (sysctl('*')) 
>> as in BSD?" as ReactOS is designed for binary compatibility with 
>> Windows, Not BSD or Linux and it should stay that way.
>>
>
> And that's why I suggested a device driver... so one can add once own 
> "extensions" without sacrificing compatibility :)
>
>> -----Original Message-----
>> From: [email protected] 
>> [mailto:[email protected]]
>> On Behalf Of Sven Barth
>> Sent: Thursday, 7 April 2011 4:05 AM
>> To: [email protected]
>> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode 
>> call for
>> syslog(2) analog in ROS
>>
>> On 06.04.2011 21:26, dmex wrote:
>>> What's wrong with current method of using the memory mapped
> 'DBWIN_BUFFER'
>>> file for outputting kernel messages?
>>>
>>
>> That I didn't know about it :P
>>
>>> Two or three different kernel implementations for the same thing 
>>> seems a bit retarded and breaks compatibility with existing 
>>> applications like
>> Dbgview.
>>>
>>
>> I'm just looking at the source of ReactOS from time to time when I 
>> have the need to check out how a certain function behaves under the 
>> hood (especially while I ported the Free Pascal compiler to the 
>> Native NT API), but I weren't yet aware how those debug outputs work.
>> As Minas mentioned that he'd like to add a syscall/API function 
>> compareable to syslog I just thought that it would be wiser (from my 
>> restricted point of
>> view) to write a driver for this that would allow to extend the 
>> system dynamically.
>>
>> Regards,
>> Sven
>>
>>> -----Original Message-----
>>> From: [email protected]
>>> [mailto:[email protected]]
>>> On Behalf Of Sven Barth
>>> Sent: Wednesday, 6 April 2011 8:54 PM
>>> To: [email protected]
>>> Subject: Re: [ros-dev] Advice required on User-mode to Kernel mode 
>>> call for
>>> syslog(2) analog in ROS
>>>
>>> Am 06.04.2011 02:09, schrieb Minas Abrahamyan:
>>>> Hi all,
>>>>
>>>> I'm going to implement dmesg.exe, a ROS application to read 
>>>> dmesg/kmsg buffer (debug messages in kernel buffer), which is 
>>>> filled in by appropriate patch 6018
>>>> (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW, 
>>>> it's not yet reviewed and not applied!).
>>>>
>>>> So I'm requesting advice on:
>>>> What would be the better way for user-mode code to get the contents 
>>>> of kmsg buffer in kernel-space (kdbg)?
>>>>
>>>> Shortly:
>>>> Linux has special system call "syslog" (man 2 syslog) FreeBSD uses 
>>>> its special sysctl interface to kernel along with 'kern.msgbuf'
>> parameter.
>>>>
>>>> My questions:
>>>> Do we need special system call like Linux, or even more, the whole 
>>>> family of them (sysctl('*')) as in BSD?
>>>> How to implement simple system call for it, now?
>>>
>>> I'm not one of the ReactOS devs and also I'm not writing much here, 
>>> but what about implementing a (legacy type) device driver that 
>>> provides a device object (e.g. \Device\kmsg) that can be read from 
>>> (no writing
>>> though) and some code for DeviceIOControl to clear/config the buffer?
>>>
>>> Regards,
>>> Sven
>>>
>>> _______________________________________________
>>> Ros-dev mailing list
>>> [email protected]
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>>
>>> _______________________________________________
>>> Ros-dev mailing list
>>> [email protected]
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> [email protected]
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> [email protected]
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> _______________________________________________
> Ros-dev mailing list
> [email protected]
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> _______________________________________________
> Ros-dev mailing list
> [email protected]
> http://www.reactos.org/mailman/listinfo/ros-dev


_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev


_______________________________________________
Ros-dev mailing list
[email protected]
http://www.reactos.org/mailman/listinfo/ros-dev

Reply via email to